Documenting 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 well-structured.
• 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 behavior 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 behavior 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 required by the customer.
• Without SRS document, it will be very much difficult for the maintenance engineers to understand the functionality of the system.
• It will be very much difficult for user document writers to write the users’ manuals properly without understanding the SRS document.
Identifying non-functional requirements
Nonfunctional requirements are the characteristics of the system which cannot be expressed as functions - such as the maintainability of the system, portability of the system, usability of the system, etc.
Nonfunctional 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
• It would be very much difficult to understand that document.
• It would be very much difficult to modify that document.
• Conceptual integrity in that document would not be shown.
• The SRS document might be unambiguous and inconsistent.
Decision tree
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
New member option
Decision: When the 'new member' option is selected, the software asks details about the member like the 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 graphical representation of the above example. After getting information from the user, the system makes a decision and then performs the corresponding actions.
Decision tree for LMS
