Write user-centred requirements specifications
The problem
According to The Standish Group1:
-
Over 30% of all software projects are cancelled before completion.
- Over 70% of the remainder fail to deliver expected features.
- The average project runs 189% over budget and overshoots its schedule by 222%.
There are many reasons for these failures, but experts agree that poor requirements management is a major culprit.
Requirements management is a systematic approach to identifying, organizing, communicating and managing the changing requirements of a digital application. Getting the requirements wrong not only contributes to the overall failure of the development effort but can be costly. An analysis by Rational Software of studies performed at GTE, TRW, and IBM found that requirements errors typically cost well over 10 times more to repair than other errors. Moreover, such errors comprise over 40% of all errors in a development project2. Small reductions in the number of requirement errors, therefore, pay big dividends in avoided rework costs and schedule delays. Clearly, you get the requirements wrong at your peril.
Ill-defined requirements result in poorly designed products with an excess of features and functions that fail to satisfy users. So, apart from adding costs and delays to your development effort, if you get the user requirements wrong you also run the risk that your product will not be accepted on the market. Production of a “lemon” is damaging for both your business and your reputation.
If getting the product requirements “right” is so important, then why do so many companies get them wrong? The key is the manner in which requirements are identified, communicated and managed. In eliciting requirements, often users are not consulted, consulted in a superficial way, or an unrepresentative sampling of users is consulted. Once requirements are gathered, they may be detailed in thick specifications that are inaccessible to business people both because of their format and because of their technical jargon. Many development efforts also suffer from serious omissions. Non-functional requirements, for example, are often ignored. The result may be a product with lovely features that is impossible to support and maintain. With so much at stake, clearly you need to get the requirements right.
The solution
Namahn works with you to develop a set of requirements that reflect the input of all stakeholders and balance their respective needs. Employing our user-centered methodology, we focus much of our requirements gathering and analysis on the important, but too often neglected, user of the product. It is the process that we employ, as much as the end result, that is key to successful requirements management.
The requirements are presented in the form of use cases. Use cases express the behaviour of a system, the functional requirements, in text that clearly outlines the sequence of steps system users will follow to benefit from using the system. Use cases can also be shown graphically in a use case diagram that provides a simple overview of the system functionality without the excessive detail which often confuses people with a less technical background.
Once the functional requirements (i.e., what the system should do) are described in the form of use cases, the non-functional requirements (i.e., how the system should work—how fast, how efficiently, how safely, etc.) are added onto the use cases so that you have a complete set of requirements.
The requirements are written from the user’s point of view, easily understandable—not only by users, but by all parties involved in the product development—and describe the design rationale (i.e., reason for specific design decisions). This means that validation can take place earlier in the process. Your product is truly fit for purpose.
The methodology
Elicitation
The key to specifying a complete set of user-oriented requirements is correctly establishing what the needs are of all the stakeholders: the users, developers, product and marketing managers. Namahn employs a range of techniques to extract the information essential for product design including:
- Contextual enquiry—observations of users in situ.
- Interviews with all the stakeholders
- Data mining
- Analysis of competing products
- Workshops—a particularly important means of gathering information required for the definition of use cases.
- Focus groups
Specification
Use cases describe the essential elements of what the system must do in an abstract, generalized and systematic way. Use cases are part of the Unified Modelling Language that is well known and understood in the software community. While following the use case framework, the use cases are presented as a narrative that uses the terminology of the domain. They are understandable to all those with a stake in the product. In addition, use cases are enhanced by models and drawings which illustrate the use cases in a more concrete way and thus are a great help in validating system requirements.
Validation
A review of the use cases by participants from the various stakeholder groups guarantees that as many situations and scenarios as possible are covered, and that the implications are well understood by all.
Prioritisation
In order to thoroughly manage the development process, the system requirements are prioritised. This can be done in the form of a MOSCOW matrix. Such a matrix distinguishes requirements that must be implemented, should be implemented, or could be implemented, i.e. would be nice to have but are not essential.
The deliverables
The requirements are specified as use case models. The model describes the sequence of interactions between the user and the system, required for the user to attain his goal. It thus ensures that:
- The basic user requirements can be met, and that common tasks can be performed and are easy to execute
- The system architecture complies with the task structure
- The technology is used effectively
- Emphasis is placed on the fundamental user requirements
The final specification is comprised of a system context definition, a system glossary, a use case model and corresponding interface designs. Scenarios of use can also be provided.
The benefits
Getting requirements right saves you money, time and frustration. Moreover, it increases the likelihood that your product will be a winner.
The user-centered approach followed by Namahn ensures that your requirements reflect the true needs of your target market. Moreover, the Namahn process facilitates smooth communication between all stakeholders.
The requirements are presented in use cases that are easy to read and understand by both technical experts and non-technical people. This minimizes misunderstandings between users, the product development team and other stakeholders. Moreover, omissions, misunderstandings or mistakes can be identified and resolved earlier in the development process. Finally, by addressing functional as well as non-functional requirements we ensure that you have specifications that detail not only product features but also address performance, reliability, security, maintainability and other critical issues.
Namahn always ensures that the solution we deliver is open. Aside from working with you to deliver comprehensive, understandable and usable requirements specifications, we ensure that the expertise in creating and using the specifications is transferred to your internal teams.
1 CHAOS, The Standish Group International, Inc., Dennis,
MA, 1994
2 “Using Requirements Management to Speed Delivery of Higher Quality
Applications,” Rational Software Corporation, Alan M. Davis and Dean
A. Leffingwell, 1995.