Requirements Engineering

Martin Weck

Dieser Artikel ist auch auf Deutsch verfügbar

Definitions

The IEEE Standard Glossary of Software Engineering Terminology [1] defines a requirement as

1. “A condition or capability needed by a user to solve a problem or achieve an objective.”
2. “A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed document.”
3. “A documented representation of a condition or capability as in 1 or 2.”

Requirements engineering addresses the question of which problems should be solved, how they should be solved and who is responsible to solve them. More precisely:

“Requirements engineering is the domain that encompasses all project life cycle activities associated with understanding a product’s necessary capabilities and attributes. It also includes requirements development and requirements management.” [2]

Requirements engineering considers three groups of requirements:

• Functional requirements specify functionality developers have to build to enable users to do their job.
• Non-functional requirements specify requirements to meet quality attributes.
• Constraints are organisational or technological restrictions that limit the degree of freedom when creating solutions.

Prof. Pohl suggests in his book [3] to avoid the notion of non-functional requirements and to replace them with quality attributes. He shows that a requirement that is neither quality attribute nor constraint can always be translated into a functional requirement. While functional requirements specify what a system should do, quality attributes specify how well the implementation must be resp. how good the system should be regarding different characteristics. If you consider the various quality attributes, you will notice that some are contradicting. Therefore, the practice will always aim to determine a reasonable compromise between the different quality attributes.

Why do we need requirements engineering?

Having defined the above notions, the question arises why we need to define requirements, constraints or quality attributes for systems that need to be modified or even designed from scratch. Users and customers start collecting requirements before any functionality is realised when they request a need that will be later fulfilled with the software in question. In general, the earlier issues in a system are detected the lower the caused costs will be. For example, it is cheaper to fix flaws in written requirements, than later to adapt the functionality of the system in operation that realises the prior defined requirements. Indeed, the highest costs in software development projects are costs caused by erroneous requirements that are detected only after a system has been delivered [3]: Errors in requirements are the most expensive types of errors.

Different statistics show [4][5] that most IT system errors are due to erroneous or missing requirements. Most often, they will remain in the long term in the system. Hence, it is possible to state: Errors in requirements are numerous and persistent.

The development of each line of code costs money. Besides costs caused by design and implementation, also tests, documentation and maintenance will cause costs. If you consider that most of IT projects are over budget (e.g. in the year 2015 19% of the projects have failed, 52% had difficulties and only 29% have been realised successfully [3]), and requirements analysis as part of requirements engineering allows to determine what should be developed, it follows that requirements engineering is also a prerequisite for the project resource planning.

Requirements engineering allows detecting errors in an early stage. Requirements validation provides an additional way to check for errors earlier than any software based test will do.

Without requirements engineering users will not be involved sufficiently (i.e. users will not accept the software once it has been created), whole user groups might be ignored (i.e. unsatisfied customers), requirements will be missed, creeping requirements might be the consequence (i.e. requirement are added continuously that in the end, the solution does not address its original purpose, where its original architecture was presuming this original former purpose), ambiguous requirements may cause the creation of wrong solutions or goals might be overreaching (aka gold-plating: functionality is implemented that has not been requested by the customer). In all these cases resources (i.e. time) are lost that can be only compensated by additional investments.

Requirements specify what should be implemented. The verification of correctness and completeness of a provided implementation is done against those requirements. The relation between correctness and completeness to the spent resources is efficiency. Hence, the efficient development of software is only possible with requirements engineering.

When do we do requirements engineering?

The development of software is highly complex knowledge work [6]. Due to the huge amount of unknown variables in software development sequential work becomes impossible. Hence, waterfall models were replaced by iterative approaches where software is created in sprints using methodologies like Scrum [7]. Since requirements engineering defines what should be developed and how good, it follows that also requirements engineering needs to be an iterative process that is interleaved with the iterative process of software development. This is less surprising if you consider that it is humans who do software development and the solving of problems by humans can be depicted as a circular process in the human brain [6]. Even though the elicitation of requirements starts before the first line of code has been written requirements engineering interleaves the iterative creation of software until the software is not further used.

If a project requires the creation of specification documents (e.g. required by a certification process) those documents will just represent a snapshot of the current situation and they need then to be updated on a regular basis.

Requirements engineering in practice

The creation of software is a complex process. Even in case of thoroughly done requirements engineering, requirements might be missed or they may change in the course of time. The creation of requirements demands to weigh competing needs to determine feasible compromises. Additionally, quality attributes that are recognized too late may cause severe consequences. Moreover, different solutions exist for given problems, which may require a choice based on incomplete information. Although participants in the project may dispose of a lot of experience, each project will require the development of a new solution due to the huge amount of parameters and different contexts for each project. The question remains, how we can do requirements engineering in practice?

The classical approach of requirements engineering foresees the steps:

• Requirements elicitation and their analysis: Software engineers and users/business experts meet to collect, consolidate and structure required knowledge.
• System modelling: the collected information is mapped into a system design (e.g. using UML).
• Requirements specification: a software requirements specification is a formal, official document that comprises all requirements based on the prior collected knowledge resp. model.
• Requirements validation: verification that the documents and models are consistent and comply with the user’s needs.
• Requirements management: creation, supervision resp. adaptation of requirements is a continuous process during the system development process.

Nowadays, software development projects utilise agile methodologies to cope with the complexity of the task at hand. The shift from a more waterfall-like approach to iterative, agile approaches does not change the task requirements engineering has to fulfil. If, for example, the project requires the creation of specification documents, they will simply reflect a snapshot of the current state of knowledge.

Domain-driven design (DDD)[8] eases the elicitation and analysis of requirements in practice. Domain storytelling[9] allows creating an understanding of existing processes. Business experts explain engineers their way of working by telling stories. The graphical representations of those stories that are created during domain storytelling may serve as a basis of process documentation. In contrast to domain storytelling, event storming[10] does not provide artefacts as a result that can be used further. However, it is the first choice if there is no one that can tell a story because a new business field needs to be explored. Similar to brainstorming business and technical participants collect system events and their chronological dependency. The common understanding serves as a basis for further system design. Domain storytelling and event storming help that business and technical experts create a common understanding and language, the so-called ubiquitous language. Knowledge retrieved through DDD allows the definition of epics. Epics can be estimated using T-shirt sizes if budgeting is required. Within the frame of agile development epics will be broken down into stories. INNOQ provides training classes on how to do DDD and assists customers in workshops when they plan to do a domain storytelling or event storming session.

The continuous use of domain storytelling or event storming might not be possible due to their complexity. Traditional methods of requirements analysis might be a good addition:

• Interviews: Users belonging to different user groups are surveyed
• Questionnaires: if users can be contacted only remotely, asynchronously, a huge number of users need to be questioned, a questionnaire may provide a good way to ask them in a systematic manner
• Observation: an analyst observes users while they use a system. Requesting the user to perform a new task that requires the use of a newly developed feature the unprejudiced reaction of the user can be studied.
• Reporting: users describe their way of working through documents. Those reports are biased, may differ strongly depending on their authors which might be compensated only partly by clear instructions on how to write them
• Brainstorming: business experts and engineers come together to collect requirements. DDD methodologies can be considered to be variants of brainstorming.

User Experience (UX) tests on a regular basis throughout the iterative software development process, e.g. every two weeks, allow to create new requirements as input for following sprints to improve, adapt the so far created software. Since the price to adapt a system increases the later the need to change the system has been noticed, providing users click dummies (e.g. figma[11] or invision[12]) for first tests instead of a fully developed, approved software may help to reduce costs. Different users may have different needs resulting in different requirements. The value proposition canvas[13] provides a good way to determine those needs. It answers three questions:

• What is the job to be done? For which purpose does the user use the developed system? Which features are used? Answering those questions helps to prioritize requirements. In an extreme scenario, features might be isolated that are not used at all.
• What pain do users have, when they use the system? Pain killers provide new requirements that are interesting to plan future sprints.
• What are the gains when using the system? The current version of the system may provide great solutions that should remain available in future versions of the system.

References