Design Process - Requirements
Defining common terminology and learning the business
When designing a new product, it's helpful
if everyone understands the same concepts and is able to talk the same
language. One mechanism to accomplish this is by defining common
terminology (i.e. glossary of terms) that the end user will be required
to know in order to successfully use the product. Every product has a
set of terms that each user must know in order to operate the product.
By defining this common terminology early in the project, it's possible
for management, the domain experts and the developers to easily
communicate and exchange ideas on how the product should behave and
function.
It is also imperative that the developers
take the time to learn the client's business. Developers should not
become domain experts but they should have a vague understanding of the
business. Too often, new developers joining a project are rushed into
the coding without a clear understanding of what they are building. Do
you really want a developer guessing on how to implement a key
requirement in the system? Take the time to educate the developers on
the business and this will result in a much higher quality application.
Capturing requirements
The quality of the end product is largely
determined by how well the requirements were captured. This step
requires a large involvement by the domain expert and/or business
analyst for the project. The domain expert/business analyst is someone
that has a thorough understanding of the domain and/or business model
and provides assistance to the development team in capturing
requirements.
Not all requirements need to be defined
before proceeding with development but at least 50% should be flushed
out before writing a single line of code. This forces the requirements
and/or business team to really think about the role and scope of the
system.
In addition to capturing each requirement prior to development, each
requirement should have a unique requirement number which can be used
to provide full requirements traceability through the application code
and test cases. This requirement number can be generated manually using
a spreadsheet or using a tool such as Rational's Requisite Pro.
On a recent consulting assignment, we had
the developers insert the requirement number in the source code
comments. A parser was then used to cross reference the requirement
numbers against the source code. This parser enabled the development
team to track the outstanding development. Inserting the requirements
number in the source code was essential in ensuring that the developers
did not forget to develop a system requirement while making it much
easier to find where each requirement was implemented. This was the
most important process followed by the development team and it greatly
improved system quality and traceability.
Prototype
Nothing is worse then spending time and
resources on something the client does not want. Clients should be
engaged early in the project lifecycle and no tool is better than
engaging the client than a prototype. The prototype should be more than
a collection of screen shots, workflows and Visio diagrams. Ideally,
the client should be presented with an interactive prototype.
For example, an HTML prototype for a web
based application can be put together fairly quickly and greatly
improves client communication as well as provide a big return on
investment (ROI). A prototype makes it easier for a client to
understand the brilliance of the user experience that is being proposed
because they can now experience it for themselves.
A prototype can also be use to disqualify
poor ideas and to solicit client input. Your client and or developers
may suggest a feature that once prototyped will demonstrate if it's
feasible or not. As well, a prototype makes the development process
much easier because it is easy to communicate to developers exactly how
the final product needs to work.
Finally, most of the code used for the
prototype is often re-used in the final development thus the effort
expended to develop the prototype is not wasted.
Use Cases
A use case is a user's view of the tasks
required to accomplish a particular job. A proper set of use cases
defined with the assistance of a domain expert provides a blueprint for
the system. A typical use case is composed of actors and the steps that
an actor takes to accomplish a particular task. The use case has a
number, a title and the requirement number that it maps to. Each use
case includes details about what has to be done by the user to
accomplish the functionality of a use case.
Ideally use cases should not make any
assumptions about the underlying infrastructure or platform. This
allows the most flexibility in the design of the system. The use cases
can also be used by the test team as a model for their test cases.
Return to Design Process
|
