In part 1 I covered how needs serve as the core to any good requirement.  The restaurant example  highlighted the key differences between needs, features and requirements.  In part 2 I showed how features, or the range of options and constraints across people process and technology, will ultimately thread user needs through the requirements specification process.  In part 3 I’ll talk about the categories of a requirement, the difference between their validation and verification and conclude with a brief summary of the linguistic features behind a good requirement.

When talking about requirements specification there are many factors to consider. First, it is important to distinguish between user requirements versus system requirements.  User requirements are typically written without any reference to a solution, technology or implementation approach.  Instead they are centered on the needs of the user in the problem domain, the characteristics and surrounding context for these needs and may incorporate elements from an overarching vision statement.   System requirements, on the other hand,  can contain references to technologies and solutions but ultimately should be written in a way so that the functional behavior and non-functional characteristics of the solution are specified without describing how they should be implemented in the solution domain, but rather how they should perform.  Use cases, for example are system requirements rooted in the solution domain that describe how the system is used and how it should behave to user input.

System requirements can also be classified as functional or non-functional in nature.  This distinction is an ongoing source of much confusion during the development lifecycle.  Functional requirements describe the desired behavior of the system whereas non-functional requirements describe the characteristics of this behavior (click here for examples of non-functional requirements from our Agile on Wall Street presentation).   Indicating that a system should first validate a user’s credentials before allowing them to proceed to the reservation booking page is an example of a functional requirement.   Indicating that this process should not take longer than one second is an example of a non-functional requirement.

Verification vs. Validation

The differences between verification and validation in the software context are similar to those between efficiency and effectiveness in the business context. For our purposes, validation refers to ensuring that the right needs are being met.  In part 1, I discussed the importance of correctly defining the user group from which needs will be elicited.   Successful software projects will prioritize the needs of this user group so they can answer the validation question – Are we doing the right thing?

Verification, on the other hand, refers to the process of ensuring the right needs are being met correctly, in other words Are we doing the thing right? Verifying a system implements a validated set of requirements is the first step towards achieving customer satisfaction.

Linguistic Characteristics

Quite simply, any stated requirement should satisfy the following criteria: unambiguous, concise, complete.

This concludes the series on Clarifying Requirements. To download a copy of this article or any other article published on The Techdoer Times please visit our table of contents page.