Requirements: Engineering (the software contract)
'Requirements engineering is the branch of software engineering concerned with the real-world goals for, functions of, and constraints on software systems. It is also concerned with the relationship of these factors to precise specifications of software behaviour, and to their evolution over time and across software families.' - (Zave, 1997)
When building a software system it is necessary to define the real world goals that motivate the development of the system. It is important to precisely analyse the system requirements and to validate that those requirements do what customers want, to define what the designers have to build, and to verify that the designers have done it in a correct way. It is also important to note that requirements can change over time and most often develop iteratively throughout the building process.
The important of collecting the requirements, functions and constraints of a proposed system cannot be overstated. It is considered the most important stage of the development process. There has been many examples over the years of projects that have catastrophically failed due to a lack of planning, one example is the London Ambulance Service's 1992 Dispatch System Failure which cost the lives of 42 people.
In the example above there were a number of project killing issues that could have been prevented if the requirements, functions and constraints had been properly examined. Here is a small list of some of the issues that caused the system to fail:
A company was used that did not have experience in large, real-time, safety-critical command and control systems.
The results of an audit were not considered in the selection process of the companies to develop the project.
Requirements were specified by a team of people who did not have a good understanding of the application field.
Requirements were very detailed, focusing on ‘how’ the system should work instead of on ‘what’ the system should do.
Some other important tasks during software development were not executed, such as quality assurance, configuration management, tracking of agreed changes and written evidence of test plans.
Identifying and Defining Problems
It is vital that when developing a software system that the problem it hopes to solve is identified and defined. This can be a challenging but van Lamsweerde (2009) has developed a framework which makes this task easier. It asks that we consider the three dimensions of requirements: why, what and who?
The why is concerned with the objectives of the software system. In this dimension we precisely define objectives, the consequences of not achieving these objectives and describing the interactions between objectives in the system.
The what is concerned with the functional services (functions) the system provides to the user in order to achieve the objectives stated above. The functional services rely on the 'operations' of the system. They need to meet the constraints of performance, security, usability, interoperability and costs.
The who dimension is concerned with the assignment of responsibilities to achieve the objectives, functionality and constraints among the components of the system. These include humans, devices and software.
Requirements of a system are attributes that satisfy the physical (type of machine, operating system, etc) or functional needs (user details to be recorded, encryption over network etc). Requirements usually describe the characteristics of a system, the properties of a system and the tasks they will execute, the action taken to carry out its tasks and any limitations to the system.
There are several characteristics associated with a set of requirements:
Correct – a requirement should conform to the understanding of the person who defined the requirement.
Necessary – a requirement should have a purpose.
Traceable – a requirement should be associated with its origins.
Non-ambiguous – a requirement should be clear and have a unique interpretation.
Feasible – a requirement should be possible to be developed in the system.
Consistent – requirements of a system should not contradict each other.
Complete – a requirement should represent a behaviour and output for all possible inputs in all states under all constraints.
Testable – a requirement should be able to be checked when implemented in a system.
The identification of a set of requirements is a difficult process and usually requires multiple iterations of the process in order to find all the requirements. Requirements are normally classified as one of two main types: functional requirements or non-functional requirements.
Functional requirements are concerned with the activities and tasks the system must carry out (the what of the system).
Non-Functional Requirements
The non-functional requirements are concerned with how the system achieves its tasks or the ways in which the system should be developed. There are different types of non-functional requirements, we can further categorise them into three groups:
These requirements are concerned with the quality properties that the system must have. Some quality properties that a system must have are below:
Safety, Security, Integrity, Availability, Reliability, Accuracy, Performance, Interface.
There are also quality requirements that must adhere to laws, regulations, social norms, cultural and political aspects and standards.
These requirements describe the way in which the system must be built. It could describe the requirements of the cost, delivery timescales, maintainability, reusability and portability.
There are several groups of people involved in the development process and use of a system. A stakeholder is a term to describe a person or group of people who are directly or indirectly affected by the system to be built. Stakeholders may influence the way the system is developed or who has responsibility for the acceptance of the system.
Some list of stakeholders are below:
the person or people who are paying for the system
people buying the software after release
familiar with the problem domain (area experts)
market researchers who conduct surveys to determine trends and needs
lawyers and auditors who are familiar with the legal and government requirements
the people involved in the development of the system (analysists, developers, testers, technical experts, engineers, designers)
Sometimes a stakeholder can fill all of the roles above or they can be distributed amongst a variety of different groups internal and external.
The purpose of identifying and defining the requirements of a system is so that we can create a 'requirements document' which acts as a contract between the contractor and the developers. It describes the requirements of the system in an unambiguous and clear way so that the client and developers are clear on the needs, functions and limitations of the system prior to building.
There are two different types of requirements definition documents:
Requirements definition document
Requirement specification document
The specification document is aimted at a technical audience such as the designers, developers, testers and project managers whereas the definition document is aimed at the clients, customers and users of the system.
The definition document provides the basis for the system before you proceed to the build. It also serves as a legal contract between the client and the developer, it should clearly define what the client has agreeed and what the developer is to produce.
They are usually written in natural, non-technical language to avoid confusion.
The requirements definition document should include the basics:
a brief description of the part of the business within which the new software system will operate – the system domain
a description of the functional requirements that the system must meet (in the form of a series of use cases)
a description of the acceptance tests that will be performed to assure the client that all the agreed behaviour is provided by the completed system
a description of the constraints in the system, when such constraints exist.
The system domain is a brief description of the real world context that the system will find itself operating in. It should only contain information that is within the scope of the system and it usually does not contain a lot of detail about the system behaviour.
The developer has to analyse the information gathered about the requirements of the system and define a set of functional requirements. The set of requirements often define what the system does and are usually presented in real life case scenarios which describe the systems functions and goals.
Acceptance testing is an activity that aims to demonstrate to the client that the system works as specified in the requirements document. If the system fails any of the acceptance tests it has failed to meet these requirements and the clients may not accept the software until further work is completed.
Constraints are defined as limitations of the new system that is being developed that must be met. Some examples of constraints are:
GUI (Graphical User Interface) must stay the same as the old version
You can only use a certain development software or language
The system must perform to a specific speed and reliability
It must be able to handle multiple concurrent users
Constraints can also occur due to external circumstances, for example laws and societal norms or regulations. You may be required to develop a system that adheres to data protection regulations, the security of data transferred over a network or accessibility concerns for the disabled.
The life cycle of requirements engineering
There are a number of phases that you will go through in the lifecycle of requirement engineering.
The first is "Domain Understanding". In this phase you are required to acquire knowledge of the context of the system (the real world scenario it will live in) and interact with stakeholders to develop a report that identifies the organisation, the domain, any identified problems and ways of addressing those problems. This will then be used in developing the requirements definition document.
The next phase is "Requirements elicitation" which is executed alongside the domain understanding activity. This activity is concerned with the identification and recording of the requirements of the system through data gathering excersises, questionnaires, surveys, teamwork based focus groups, prototyping, model-driven techniques.
The next stage is "Requirements evaluation and negotiation". In this activity, identified requirements are analysed in terms of conflicts, risks, alternative options, priorities, completeness and ambiguity. It may be necessary to hold negotiations with the clients and come to a consensus which results in sections of the requirements definition document.
In the next stage "Requirements specification and documentation" we develop the requirements definition document in the form of a template using a variety of inputs such as general objectives, system requirements, software requirements, environmental assumptions etc.
The final stage is "Quality Assurance". In this stage we check that the system is meeting the requirements as set out in the requirements definition document and if they comply with any necessary laws and regulations. It is at this stage that the developers will check that the right product is being built (validation) and that the product is being built correctly (verification). It is the hope that by the end of this stage you will have produced a product has detected all errors and all the problems are fixed.