Requirements Analysis & Specification - 1 | Embedded Systems (Web) - Computer Science Engineering (CSE) PDF Download

Introduction
The requirements analysis and specification phase starts once the feasibility study phase is complete and the project is found to be technically sound and feasible. The goal of the requirements analysis and specification phase is to clearly understand customer requirements and to systematically organize these requirements in a specification document. This phase consists of the following two activities:

• Requirements Gathering And Analysis
• Requirements Specification

Requirements Gathering And Analysis 
The analyst starts requirements gathering and analysis activity by collecting all information from the customer which could be used to develop the requirements of the system. He then analyses the collected information to obtain a clear and thorough understanding of the product to be developed, with a view to removing all ambiguities and inconsistencies from the initial customer perception of the problem. The following basic questions pertaining to the project should be clearly understood by the analyst in order to obtain a good grasp of the problem:

• What is the problem?
• Why is it important to solve the problem?
• What are the possible solutions to the problem?
• What exactly are the data input to the system and what exactly are the data output by the system?
• What are the likely complexities that might arise while solving the problem?
• If there are external software or hardware with which the developed software has to interface, then what exactly would the data interchange formats with the external system be? 

After the analyst has understood the exact customer requirements, he proceeds to identify and resolve the various requirements problems. The most important requirements problems that the analyst has to identify and eliminate are the problems of anomalies, inconsistencies, and incompleteness. When the analyst detects any inconsistencies, anomalies or incompleteness in the gathered requirements, he resolves them by carrying out further discussions with the endusers and the customers.

SRS Document 
After the analyst has collected all the requirements information regarding the software to be developed, and has removed all the incompleteness, in consistencies, and anomalies from the specification, he starts to systematically organize the requirements in the form of an SRS document.

The important parts of SRS document are:

• Functional requirements of the system
• Non-functional requirements of the system, and
• Goals of implementation

Functional Requirements 
The functional requirements part discusses the functionalities required from the system. Here we list all high-level functions {f_i} that the system performs. Each high-level function fi, as shown in fig. 34.1, is considered as a transformation of a set of input data to some corresponding output data. The user can get some meaningful piece of work done using a high-level function.

Fig. 34.1 Function f_i

Non-Functional Requirements
Non-functional requirements deal with the characteristics of the system which can not be expressed as functions - such as the maintainability of the system, portability of the system, usability of the system, etc.

Non-functional requirements may include:

• Reliability issues
• Accuracy of results
• Human-computer interface issues
• Constraints on the system implementation, etc.

Goals of Implementation 
The goals of implementation part documents some general suggestions regarding development. These suggestions guide trade-off among design goals. The goals of implementation section might document issues such as revisions to the system functionalities that may be required in the future, new devices to be supported in the future, reusability issues, etc. These are the items which the developers might keep in their mind during development so that the developed system may meet some aspects that are not required immediately.

Identify Functional Requirements 
The high-level functional requirements often need to be identified either from an informal problem description document or from a conceptual understanding of the problem. Each highlevel requirement characterizes a way of system usage by some user to perform some meaningful piece of work. There can be many types of users of a system and their requirements from the system may be very different. So, it is often useful to identify the different types of users who might use the system and then try to identify the requirements from each user’s perspective.
Here we list all functions {fi} that the system performs. Each function fi, as shown in fig. 34.1, is considered as a transformation of a set of input data to some corresponding output data.
Example 
Consider the case of the library system, where –
F1: Search Book function (fig. 34.2)
Input: An author’s name
Output: Details of the author’s books and the location of these books in the library

Fig. 34.2 Book Function 

So, the function Search Book (F1) takes the author's name and transforms it into book details.
Functional requirements actually describe a set of high-level requirements, where each highlevel requirement takes some data from the user and provides some data to the user as an output. Also each high-level requirement might consist of several other functions.

Document Functional Requirements 
For documenting the functional requirements, we need to specify the set of functionalities supported by the system. A function can be specified by identifying the state at which the data is to be input to the system, its input data domain, the output data domain, and the type of processing to be carried on the input data to obtain the output data. Let us first try to document the withdraw-cash function of an ATM (Automated Teller Machine) system. The withdraw-cash is a high-level requirement. It has several sub-requirements corresponding to the different user interactions. These different interaction sequences capture the different scenarios.

Example: Withdraw Cash from ATM
R1: withdraw cash 
Description: The withdraw cash function first determines the type of account that the user has and the account number from which the user wishes to withdraw cash. It checks the balance to determine whether the requested amount is available in the account. If enough balance is available, it outputs the required cash, otherwise it generates an error message.

R1.1: select withdraw amount option 
Input: “withdraw amount” option
Output: user prompted to enter the account type

R1.2: select account type 
Input: user option
Output: prompt to enter amount

R1.3: get required amount 
Input: amount to be withdrawn in integer values greater than 100 and less than 10,000 in multiples of 100.
Output: The requested cash and printed transaction statement. Processing: the amount is debited from the user’s account if sufficient balance is available, otherwise an error message displayed.

Properties of a Good SRS Document 
The important properties of a good SRS document are the following:
Concise: The SRS document should be concise and at the same time unambiguous, consistent, and complete. Verbose and irrelevant descriptions reduce readability and also increase error possibilities.
Structured: It should be well-structured. A well-structured document is easy to understand and modify. In practice, the SRS document undergoes several revisions to cope up with the customer requirements. Often, the customer requirements evolve over a period of time. Therefore, in order to make the modifications to the SRS document easy, it is important to make the document wellstructured.
Black-box view: It should only specify what the system should do and refrain from stating how to do these. This means that the SRS document should specify the external behaviour of the system and not discuss the implementation issues. The SRS document should view the system to be developed as black box, and should specify the externally visible behaviour of the system. For this reason, the SRS document is also called the black-box specification of a system.
Conceptual integrity: It should show conceptual integrity so that the reader can easily understand it.
Response to undesired events: It should characterize acceptable responses to undesired events. These are called system response to exceptional conditions.
Verifiable: All requirements of the system as documented in the SRS document should be verifiable. This means that it should be possible to determine whether or not requirements have been met in an implementation.

Problems without a SRS Document 
The important problems that an organization would face if it does not develop an SRS document are as follows:
• Without developing the SRS document, the system would not be implemented according to customer needs.
• Software developers would not know whether what they are developing is what exactly is required by the customer.
• Without SRS document, it will be very difficult for the maintenance engineers to understand the functionality of the system.
• It will be very difficult for user document writers to write the users’ manuals properly without understanding the SRS document.

Identify Non-Functional Requirements 
Non-functional requirements may include:
• Reliability issues
• Performance issues
• Human - computer interface issues
• Interface with other external systems
• Security and maintainability of the system, etc.

Problems with An Unstructured Specification 
The problems that an unstructured specification would create during software development are as follows:
• It would be very difficult to understand that document.
• It would be very difficult to modify that document.
• Conceptual integrity in that document would not be shown.
• The SRS document might be ambiguous and inconsistent.

Techniques for Representing Complex Logic 
A good SRS document should properly characterize the conditions under which different scenarios of interaction occur. Sometimes such conditions are complex and several alternative interaction and processing sequences may exist. There are two main techniques available to analyze and represent complex processing logic:
decision trees and decision tables.

 1. Decision Trees 
A decision tree gives a graphic view of the processing logic involved in decision making and the corresponding actions taken. The edges of a decision tree represent conditions and the leaf nodes represent the actions to be performed depending on the outcome of testing the condition.
Example 
Consider Library Membership Automation Software (LMS) where it should support the following three options:
• New member
• Renewal
• Cancel membership

New member option 
Decision: When the 'new member' option is selected, the software asks details about the member like member's name, address, phone number etc.
Action: If proper information is entered, then a membership record for the member is created and a bill is printed for the annual membership charge plus the security deposit payable.

Renewal option 
Decision: If the 'renewal' option is chosen, the LMS asks for the member's name and his membership number to check whether he is a valid member or not.
Action: If the membership is valid then membership expiry date is updated and the annual membership bill is printed, otherwise an error message is displayed.

Cancel membership option 
Decision: If the 'cancel membership' option is selected, then the software asks for member's name and his membership number.
Action: The membership is cancelled, a cheque for the balance amount due to the member is printed and finally the membership record is deleted from the database. Decision tree representation of the above example The following tree (fig. 34.3) shows the graphical representation of the above example. After getting information from the user, the system makes a decision and then performs the corresponding actions.




2. Decision Tables 
A decision table is used to represent the complex processing logic in a tabular or a matrix form. The upper rows of the table specify the variables or conditions to be evaluated. The lower rows of the table specify the actions to be taken when the corresponding conditions are satisfied.
Example 
Consider the previously discussed LMS example. The decision table shown in fig. 34.4 shows how to represent the problem in a tabular form. Here the table is divided into two parts. The upper part shows the conditions and the lower part shows what actions are taken. Each column of the table is a rule.

Fig. 34.4 Decision table for LMS 

From the above table you can easily understand that, if the valid selection condition is false, then the action taken for this condition is 'display error message' and so on.

Formal Requirements Specification 
A formal technique is a mathematical method to specify a hardware and/or software system, verify whether a specification is realizable, verify that an implementation satisfies its specification, prove properties of a system without necessarily running the system, etc. The mathematical basis of a formal method is provided by the specification language.

Formal Specification Language 
A formal specification language consists of two sets syn and sem, and a relation sat between them. The set syn is called the syntactic domain, the set sem is called the semantic domain, and the relation sat is called the satisfaction relation. For a given specification syn, and model of the system sem, if sat(syn, sem) as shown in fig.34.5, then syn is said to be the specification of sem, and sem is said to be the specificand of syn.




Syntactic Domains 
The syntactic domain of a formal specification language consists of an alphabet of symbols and set of formation rules to construct well-formed formulae from the alphabet. The well-formed formulae are used to specify a system.

Semantic Domains 
Formal techniques can have considerably different semantic domains. Abstract data type specification languages are used to specify algebras, theories, and programs. Programming languages are used to specify functions from input to output values. Concurrent and distributed system specification languages are used to specify state sequences, event sequences, statetransition sequences, synchronization trees, partial orders, state machines, etc.

Satisfaction Relation 
Given the model of a system, it is important to determine whether an element of the semantic domain satisfies the specifications. This satisfaction is determined by using a homomorphism known as semantic abstraction function. The semantic abstraction function maps the elements of the semantic domain into equivalent classes. There can be different specifications describing different aspects of a system model, possibly using different specification languages. Some of these specifications describe the system’s behaviour and the others describe the system’s structure. Consequently, two broad classes of semantic abstraction functions are defined: those that preserve a system’s behaviour and those that preserve a system’s structure.