Requirement engineering

Chapter 7

The goal of the requirement engineering is to create and maintain a system requirement document. The overall process includes four high-level sub-processes. These are concerned with assessing whether the system is useful to the business (feasibility study); discovering requirements (elicitation and analysis); converting these requirements into some standard form (specification); and checking that the requirements actually define the system that the customer wants (validation). Feasibility study produces feasibility report and leads to next process – requirements elicitation and analysis. Then, system models and requirements specification produced, next – user and system requirements and requirements validation processes come, and as result of all these sub-processes (they also rely on each other during requirement engineering process) the requirement document developed.

Feasibility studies answers number of questions:

1. Does the system contribute to the overall objectives of the organisation?
2. Can the system be implemented using current technology and within given cost and schedule constraints?
3. Can the system be integrated with other systems which are already in place?

In a feasibility study in it often that you consult information sources such as the managers of the departments where the system will be used, software engineers who are familiar with the type of system that is proposed, technology experts and end-users of the system.

In the next stage, the requirements elicitation and analysis, software engineers work with customers and end-users of a system to find out about application domain, what services the system should provide, the general performance of the system. When these general requirements are ready, developers should check if the requirements actually define the system that the customer wants. These checks include:

• Validity checks. Further thought and analysis may identify additional or different functions that are required.
• Consistency checks. Requirements should not conflict.
• Completeness checks. Requirement document should include requirements, which define al functions and constraints intended by the system user.
• Realism checks. Using knowledge of existing technology, the requirements should be checked to ensure that they could actually be implemented.
• Verifiability. To reduce the potential for dispute between customer and contractor, system requirements should always be written so that they are verifiable.

The requirements for large project are always changing. Often, because the problem cannot be fully defined, the software requirements are bound to be incomplete. Requirement management is the process of understanding and controlling changes to system requirements. This includes keeping track of individual requirements and maintaining links between dependent requirements, establishing a formal process for making change proposals and linking these to system requirements.

My thoughts:

Requirements are, I believe, the most known part of this book to me. We discussed requirements quite a lot, and I see why they are important. During requirement engineering process (if I can call it that fancy way :) ) for our Monopoly game, we faced problems, discussed in this chapter. For example, some sort of consistency checks were done after Iteration 1 and we found some requirements conflicts and overlap one another. Completeness check showed that we still missing two requirements, not really important and basic ones, but still, if we were starting implementation, at some point we would come back and think again. We didn’t do any feasibility studies, except for maybe one question – “Can the system be implemented using current technology and within given cost and schedule constraints?”. Given cost is a term mark and schedule was set, so we didn’t really deep thinking and analysing. For large and real project, this is much more serious questions.