Requirements Engineering
Requirements engineering is concerned with systems where a system is a set of components (humans, human procedures, physical devices, software) interacting with each other to meet global objectives.
Why: From a system-as-is we find objectives to create a system-to-be. We start from problems, opportunities and domain knowledge. What: We figure out the requirements, constraints and assumptions. Who: Find out what can meet the requirements. (software-to-be, people, devices, processes, existing software)
Stakeholders can provide requirements, impose constraints or invalidate assumptions. If you fail to consult the correct stakeholders, you may miss out on a set of requirements.
- System-to-be: developers
- Operational area: normal and maintenance operators
- Containing business: customer, sponsor, functional beneficiaries
- Wider environment: subject matter expert, negative stakeholders, financial beneficiaries, political beneficiaries, regulators
A typical process model works by:
Link to original
- Taking information from stakeholders, existing systems, documents.
- Elicitation & domain analysis Finding functional requirements: what the system can do Finding non-functional requirements: how the software / system should work We could do a background study, interview, workshop, observation / user study, survey / questionnaire, or user forum / feature requests.
- Negotiation & Prioritisation Goals are broken down into sub-goals which may show if there are any conflicts
- Specification & Documentation` Authoring a specification documents, may use different visual tools.
Looking at the world
Between “the world” and “the machine”:
Descriptive Statement
Descriptive statements express something that is true about a system.
Link to original
Prescriptive Statement
Prescriptive statements express something that should be true about a system.
Link to original
From requirements to specifications
A complete requirements specification satisfies the following property: Any set of specification and domain properties / assumptions must entail a set of requirements. They must also be consistent with one another.
We form the following from different scenarios:
| World phenomena | Shared phenomena | Machine phenomena | |
|---|---|---|---|
| Descriptive | Domain property | ||
| Prescriptive | Requirement / domain assumption | Machine specification |
Analysis
Domain Analysis
A domain analysis should include:
Link to original
- Requirements
- Machine specifications
- Domain properties
- Domain assumptions
- Definitions of key terms
Seven sins of the specifier
We can define bad requirements using the Seven sins of the specifier (Meyer, 1985):
Link to original
- Noise: irrelevant information
- Silence: the problem has a feature that is not mentioned by the text
- Over-specification: specification of a solution to the problem, not the problem
- Contradiction: text contains elements that describe the same feature in incompatible ways
- Ambiguity: text can be interpreted in different, mutually incompatible ways
- Forward reference: text uses a feature that is not defined until later
- Wishful thinking: description of a problem does not permit realistic validation