In part 1 I discussed how user needs are at 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 thread these user needs through to 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 and 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,  contain references to technologies and solutions but ultimately should be written so that the functional behavior and non-functional characteristics of the solution are specified without describing how they should be implemented.  Use cases, for example are system requirements rooted in the solution domain that describe how the system is used and how it should respond 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.  Functional requirements describe the 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 authenticate a user’s credentials before allowing him to proceed to the reservation booking page is an example of a functional requirement.   Indicating that this process should take no 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 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 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 correct implementation of these needs.  In other words, verification answers the question - Are we doing the thing right?

Any project that begins the software development phase with a validated set of requirements, and finishes the software deployment phase by verifying this set, is on the brink of satisfying customer demands.

Linguistic Characteristics

Quite simply, any stated requirement should satisfy the following criteria: the requirement should be written in such a way so that it is unambiguous, concise, and complete.

This concludes the series on Clarifying Requirements.  If you have any questions or comments on this article please email techdoer@gmail.com.