By Dr. Abdulrahman H. Altalhi Computing: An Object-Oriented Approache CHAPTER 32 Requirements Analysis Notes On the slide By Dr. Abdulrahman H. Altalhi

Introduction Before developing a software, the software developer should know exactly what the client requires. The client and software developer have to work together to get to a situation where each party fully understands what is required of the software. This chapter introduces you to this process, which is known as requirements analysis. Once the software developer fully understands what the client wants, a precise specification for the software is written. This specification is known as the negotiated statement of requirements and represents an agreement between the client and the software developer about what the software will do.

1 Specifying software The starting point of any software project is a document prepared by the client for a proposed software system, known as the statement of requirements. This document, which is usually written in a natural language such as English, can be a few pages in length or can consist of several volumes of text. Its primary purpose is to describe the application area that is, the real-world context within which the system is required to operate, and what the client requires of the system. Specifying even a small application can involve many questions and answers; this is the essence of requirements analysis.

1 Specifying software Fundamental classification of the kinds of information typically present in Statement of Requirement documents: Information about what the client wants the system to do; This type of information is known as a behavioral requirement. Information about a limitation on the system; that is, that the response time of the command must be no more than two seconds. This type of information is known as a constraint.

1 Specifying software Analyzing the statement of requirements Given a statement of requirements, the developer has to carry out the process of requirements analysis. Requirements analysis consists of analyzing the statement of requirements and extracting and clarifying the important parts; that is, the behavior and the constraints. It involves a period of considerable interaction with the client and can be the most difficult part of the software project. Why is it so difficult?

1 Specifying software Answer: First, it involves two parties. One of these is an expert in computing while the other is an expert in the particular application Hence, there can be a considerable ‘culture gap’ between the two parties. Second, the statement of requirements usually has certain properties, listed below, which make the task of requirements analysis difficult. Behavioral requirements and constraints are intermingled. The statement of requirements contains ambiguities. The statement of requirements contains platitudes. The constraints include design and implementation directives. There are omissions in the statement of requirements. Behavior is described at different levels of detail.

1 Specifying software Behavioral requirements and constraints are intermingled Statements of requirements are rarely structured neatly into functions and constraints because the client writing the document will not usually think in terms of these categories of information. Thus the information is often intermingled. The statement of requirements contains ambiguities Ambiguities arise from the use of natural language and occur frequently since natural language is the only medium through which the client is able to communicate with the developer. The statement of requirements contains platitudes Probably the most common example of a platitude is the sentence below. The system should have a user-friendly interface.

1 Specifying software The constraints include design and implementation directives A design directive is a statement limiting the choices of the developer in designing the software. An example of such directives are shown below. The salary details of staff should be held in a dictionary structure whose key is the staff number. There are omissions in the statement of requirements In describing large systems it is extremely easy to leave out details. Detailing what should happen if invalid data is input is a frequent omission. Behavior is described at different levels of detail In a statement of requirements, behavior is often described at different levels of abstraction.

1 Specifying software The negotiated statement of requirements The purpose of requirements analysis is to produce a document called a Negotiated Statement Of Requirements (NSR). This should express, in an unambiguous way, what a proposed system should do – its behavior – and what the limitations on the software developer are − that is, the various kinds of constraints. if it is difficult to initially define what is required of the software or if what is required is very complicated, an iterative approach is sometimes employed to assist in the analysis of requirements. In such an approach, a simplistic NSR is produced initially, from which a prototype system is developed. This is a partial system, which is evaluated and used to refine the requirements. A more advanced system is then developed, and so on

1 Specifying software The part of the NSR that gives details of the behavior of the system will often be the largest of its sections; it is known as the behavioral specification. It should ideally have a number of properties, which are listed and then discussed below. The behavioral specification should be unambiguous. The behavioral specification should be in a form that enables the developer to reason about the properties of the system it describes. The behavioral specification should be free of extraneous detail. The behavioral specification should be partitioned. The behavioral specification should be understandable by the client.

1 Specifying software The behavioral specification should be unambiguous You have already seen that statements of requirements can contain vague statements about system functions. The behavioral specification should be in a form that enables the developer to reason about the properties of the system it describes During the requirements analysis process the developer will be continually developing the behavioral specification and checking that the properties of the proposed system match the client’s view of what it should do. The behavioral specification should be free of extraneous detail By this we mean that it should only contain information relevant to the current task. Properties that are important to the client must be easily identified and should not be hidden by too much detail.

1 Specifying software The behavioral specification should be partitioned Information in a behavioral specification should be partitioned hierarchically into self-contained sections.

1 Specifying software The behavioral specification should be understandable by the client Once the negotiated statement of requirements is complete, it must be read, approved and agreed by the client. In the contract for a system there is normally a clause stating that the NSR must be agreed by both the client and the developer and that, once this agreement is reached, no more changes may be made to it without the permission of both parties.

2 Eliciting information The main way of eliciting information is to ask questions, and in this section we shall look at the sorts of questions you might ask in the various areas. It may be that a perceived need for a system is actually the result of poor administrative procedures Unless the issue is explored at the beginning of a project, there is a danger either of replicating poor procedures within the new software, or of implementing new administrative procedures without sufficient cognizance of the original problems.

2.1 Categories of questions Scoping Questions These are questions that attempt to delineate what facilities should be in a system and what facilities should not be included. Questions about input data A common category of question involves the information or data that is to be processed by a system. Questions about output data Another category of question involves the data that is to be output. Questions about behavior An important category of questions concerns what the system should do. These questions will range from very broad questions to very detailed ones.

2.2 Overlapping categories of questions An important point to notice about the questions we have asked above is that, although we have tried to place each of them in a category, in real life things are never so simple: a question will often involve a combination of concerns involving detailed system functions, input data, output data and scoping.