Summary of 'Writing Better Requirements - Styles and Techniques' Ch01
This chapter begins with a review of requirements specification not only as a phase previous to software development achieved in a linear waterfall o iterative manner, but also as a contract between customer and supplier which can be used as an evidence of what was agreed.
The stakeholders’ demands are transformed into consistent, feasible, complete requirements through elicitation, analysis and formulation processes. In these processes, problems like vague, conflicting, missing, changing requirements must be resolved by validation, however not every demand can be specified (tacit requirement) due to such problems or the extent of the specification document.
The chapter then follows explaining the different roles that requirements play in different types of projects when showing who can be the customer and the supplier and what one party expects from the another one. The requirements engineer has to write up the specification document choosing a different methodology or technique depending if the project is an In-house development, a product development, a time-and-material based development, a Commercial Off-The-Shelf (COTS) purchase, a tender, a contract development, or a subtract development.
The next section talks about the contents of the requirements specification document such as data requirements, functional requirements, quality requirements, managerial requirements and other deliverables. However, many requirements engineers write up that specification just as a long list of requirements numbered in some order, forgetting to include special sections for the rationale of each requirement (why it is important, what problem it solves) and for the business goals (success criteria of the system) that helps for validation, tracking and verification processes.
Then we have the following four problems observed in practice:
- Developers can detect incomplete, wrong, ambiguous, and badly phrased requirements and re-interpret them such that the system, layer or component works as needed, but the problems have not corrected in the specification document.
- Customers do not satisfy their expectations even when the system complains with the requirements specification. This is due to insufficient or inaccessible functionality not well gathered by the requirements engineering when not stating explicitly business goals and not tracing them to requirements.
- Crucial background information that helps the reader, supplier or customer, to understand the real needs and expectations are missing.
- Quality requirements are little specified which also leads to a poor, unacceptable final system.
The requirements specification must distinguish between product-level requirements and domain-level requirements, that is, what goes in and out of the product and what activities the requirement have to give support. The boundaries of these product-level and domain-level requirements have to be defined clearly in order to develop the right product the customer needs without infringing the contract or incurring in over budgets.
The requirements engineer also faces the problem of choosing the adequate level of requirements for delivery depending on the type of supplier that will develop the final system. Goal-level, Domain-level, Product-level and Design-level requirements are not suitable for every supplier because he can reject accepting risks that are under the entirely customer’s responsibility. Choosing the right level or combination of levels in the goal-design scale ensures good suppliers and high customer satisfaction.
In the final section of this chapter, we see three different project models for the requirements engineering process each of them has special characteristics suitable for certain types of final products:
1. Product-level requirements
This is the traditional process where the requirements engineer asks users and stakeholders and analyses existing documents to discover and write up the requirements himself on a document containing an introduction, the business goals, the system limits, the data requirements, the product-level functional requirements and the critical quality requirements. It requires great analysis time and its weakness is the difficulty to ensure that those product-level requirements guaranties adequate support for user tasks and satisfaction for business goals.
2. Domain-level requirements
This is the fast model where the requirements engineer describes the user tasks together with expert users to write up the requirements as a background of a user task traced through the business goals on a document something similar to that produced by the product-level based model. It reduces the time spent in analysis processes up to 10 times, but some functional requirements are not easy to specify using user tasks.
3. Domain-level requirements plus design-level requirements
This model consists of two steps, the first is the domain-level model previously explained and the second is a design-level specifying complex interfaces like user ones and communication ones. The proposed prototypes are valid if they fulfill the domain-level requirements obtained in the first step; in this way while the prototypes shows the design requirements, the domain-level requirement justify those prototypes.
You can read in the book about what kind of development projects these models are for and how many they can cost –your salary. Why this book is interesting to me? Because it has this promise: to teach me a better way for requirements specification using styles and tasks on proven real life projects than just using uses cases.
