Functional Requirements
The chapter looks at the requirements that a product must satisfy to be successful or meaningful. These requirements should be defined alone before describing any technology to implement those requirements. The requirements should contain all the details so that the developers can understand these properly.Uncovering the Functional Requirements
The scenarios help a lot to describe the requirements. Scenarios are created by partitioning the work using the business events that affect it. For each business event, there is a business use case that responds to the business event, and a BUC scenario describes this functionality from the business point of view. From this BUC, product use cases are created.
PUC enables the business stakeholders and developers to have an overview of the functionality. The steps should be recognizable by stakeholders.
Description and Rationale
For every described requirement, there should be a rationale included to show why the requirement exists. By including a rationale with the description, the requirement itself becomes more useful. By knowing why something is there, the developers and the testers know much more about the effort they should put on it. It also indicates to future maintainers why the requirement exists in the first place. The rationale also helps to overcome the possibility of inadvertently writing a solution instead of the real need.
Data, Your Secret Weapon
After doing the description and rationale, there comes the data dictionary. The flows should be defined by listing their attributes and then those attributes enable us to develop a business data model. This model acts as a definition of functional requirements.
Data Models
The class model shows the classes (or entities) as rectangles. A class is a logical collection of data attributes that is needed by the product to carry out its functionality. The lines between the classes indicate an association between two classes and the name on the line indicates the reason for the association. The asterisks and the 1s define the multiplicity of the association.Here is an example to explain the data model for the IceBreaker Project.
Exceptions and Alternatives
Exceptions are unwanted but unavoidable deviations for the normal case caused by errors of processing and incorrect actions.
Alternatives are allowable variations from the normal case, which are provided at the commands of stakeholders.
Thank you Harjeet,
ReplyDeleteI would like to explain more about Level of Detail or Granularity
Note the level of detail in the preceding examples—the requirements are
written as a single sentence with a single verb. When you write this single
sentence, you make the requirement much easier to test and far less susceptible
to ambiguity. Note also the form “The product shall . . .”; it makes the sentence
active and focuses on communicating what the product is intended to
do. It also provides a consistent form for the developers and other
stakeholders who need to have a clear understanding of what the product is intended
to do. You can of course substitute “will” for “shall” (some people claim is it
grammatically better), but be consistent with whichever you choose.
Incidentally, the word “shall” does not mean that you will definitely be
able to find a solution to satisfy the requirement; it simply means that the
requirement is a statement of the business intention. The developers are
charged with deriving a technological solution to the requirement, and naturally
there will be times when they cannot find a cost-effective solution. In
the meantime, the requirement clarifies what the business needs the product
to do. One last word on the form employed to write the requirements description:
Sometimes people use a mixture of “shall,” “must,” “will,” “might,” “could”
and so on, to indicate the priority of a requirement. This practice results in
semantic confusion, and we advise against it. Instead, use one consistent form
for writing your requirements’ descriptions (“The product shall . . .” is the
most common) and use a separate attribute of the requirement to identify its
priority.
Alternatives to functional Requirements
ReplyDeleteScenarios
if
the intended product is routine and the business area well understood, and
if your developers are experienced and willing to collaborate, you might
consider simply adding implementation details to the scenario, and use that
as your specification. With this approach, you might have to revise the scenario
a little to make the steps read from the point of view of the product.
You and your developers and testers must be confident that they can write
and test the product based on this enhanced scenario.
If the scenario becomes too long or too elaborate, then revert to writing
the functional requirements in the normal manner.
Do not follow this path if you are outsourcing construction to an external
supplier or another department in your organization. For outsourcing, it is
better to avoid the increased potential for misinterpretation by writing the
atomic functional requirements.
user Stories
The intention of the story card is not to specify the requirements, but
rather to act as a starting point, or placeholder, for the requirements. These
are discovered as development progresses through conversations between
the developers and the stakeholders. Stories are usually written on cards,
and the developers annotate the cards with their fleshed-out requirements
and the necessary test cases.
Talking about function requirement, it’s important to mention the exceptions and alternatives that maybe should be used during the project. The exception requirement just happens if the exception really exists. The alternative requirement allows some variation from the normal case. The conditional requirement just happened when certain processing circumstance occur.
ReplyDeleteThe technological requirement refers to aspects such as performance and availability that the software or equipment must meet to the success of the project. In a software project, know how the software is build, for example, what type of operation system and programing language it is really important.