UNIT 2
Software Requirements Analysis, User Needs, Software Features and Requirements Engineering
“A condition or capability needed by a user to solve a problem or achieve an objective” or “ The capability possessed by a system to satisfy a contract, standard, specification, or other formally imposed documents”.
When users request for software, they possess an approximation of what the new system should be capable of doing. Requirements differ from one user to another user and from one business process to another business process. Reliability means Operational reliability. It is described as the ability of a system or component to perform its required functions under static conditions for a specific period.it can also be described as the probability that a software system fulfils its assigned task in a given environment for a predefined number of input cases, assuming that the hardware and the input are free of error.
Software can be defined as a collection of programs, documentation and operating procedures. Institute of Electrical and Electronic Engineers (IEEE) defines software as “a collection of computer programs, procedures, rules, and associated documentation and data”.
Features of software:
Functionality: Refers to the degree of performance of the software against its intended purpose.
• Reliability: Refers to the ability of software to perform a required function under given conditions for a specified period.
• Usability: Refers the degree to which software is easy to use.
• Efficiency: Refers to the ability of software to use system resource in the most effective and efficient manner. • Maintainability: Refers to the ease with which a software system can be modified to add capabilities, improve system performance, or correct errors.
• Portability: Refers to the ease with which software developers can transfer software from one platform to another, without (or with minimum) changes
“Gathering software requirements is the foundation of the entire software development project. Hence they must be clear, correct and well-defined.”
Software Requirements Characteristics:
Type of requirements:
Classes of User Requirements: Enduring and Volatile
Requirement elicitation is a process in which users are encountered with different methods to get user requirements out of them.
Following are the steps for Requirement elicitation -
Requirement analysis is significant and essential activity after elicitation. We analyse, refine, and scrutinize the gathered requirements to make consistent and unambiguous requirements. This activity reviews all requirements and may provide a graphical view of the entire system. After the completion of the analysis, it is expected that the understanding of the project may improve significantly. Here, we may also use the interaction with the customer to clarify points of confusion and to understand which requirements are more important than other.
The process to gather the software requirements from client, analyse and document them is known as requirement engineering main goal of requirement engineering is to develop and maintain sophisticated and descriptive ‘System Requirements Specification’ document.
Requirement Engineering Process includes four steps:
a) Feasibility Study
b) Software Requirement Specification
c) Requirement Gathering
d) Software Requirement Validation
Feasibility study
When the client approaches the organization for getting the desired product developed, it comes up with rough idea about what all functions the software must perform and which all features are expected from the software. Referencing to this information, the analysts does a detailed study about whether the desired system and its functionality are feasible to develop.
This feasibility study is focused towards goal of the organization. This study analyses whether the software product can be practically materialized in terms of implementation, contribution of project to organization, cost constraints and as per values and objectives of the organization. It explores technical aspects of the project and product such as usability, maintainability, and productivity and integration ability.
The output of this phase should be a feasibility study report that should contain adequate comments and recommendations for management about whether or not the project should be undertaken.
Software Requirement Specification-
SRS is a document created by system analyst after the requirements are collected from various stakeholders. It defines how the intended software will interact with hardware, external interfaces, speed of operation, response time of system, portability of software across various platforms, maintainability, speed of recovery after crashing, Security, Quality, Limitations etc. The requirements received from client are written in natural language. It is the responsibility of system analyst to document the requirements in technical language so that they can be comprehended and useful by the software development team.
Requirement Gathering
If the feasibility report is positive towards undertaking the project, next phase starts with gathering requirements from the user. Analysts and engineers communicate with the client and end-users to know their ideas on what the software should provide and which features they want the software to include.
Software Requirement Validation
After requirement specifications are developed, the requirements mentioned in this document are validated. User might ask for illegal, impractical solution or experts may interpret the requirements incorrectly. This results in huge increase in cost if not nipped in the bud. Requirements can be checked against following conditions -
The software requirements are description of features and functionalities of the target system. Requirements convey the expectations of users from the software product. The requirements can be obvious or hidden, known or unknown, expected or unexpected from client’s point of view.
Requirements structuring is the process to use some kind of systematically and standard, well-structured methods to model the real world. Traditionally, we use data flow diagram for process modeling, decision table or decision tree for logic modeling, and Entity-relationship diagram for data modeling. These modeling tools usually separately model only one face of the real world. So, when we try to show the integral picture of a system, we usually choose more than one of the above requirements structuring methods.
Some of the tools for requirement gathering are mentioned below:
Data Flow Diagrams: It gives an overview of what data a system processes, what transformations are performed, what data are stored, what results are produced and where they flow
Data Dictionary: A data dictionary is a structured repository of data elements in the system. It stores the descriptions of all DFD data elements that is, details and definitions of data flows, data stores, and data stored in data stores, and the processes.
Decision Trees: A decision tree is a diagram that shows relation between actions and conditions within horizontal tree framework.it shows which conditions to evaluate first hence the flow of execution for condition can be understood easily.
Decision Tables: Decision tables are tables made up of two components namely stub and entry named as action stub, condition stub, condition entry, action entry which describes the relationship between actions and conditions very easily. In short It is a matrix containing row or columns for defining a problem and the actions.
Requirements, which are not conventional are called non-traditional requirements.
Non-functional requirements include -
CASE STUDY: STUDENT ADMISSION ANDEXAMINATION SYSTEM
A University is willing to automate its admission and examination system. The main objective of developing this software product is to help the university in managing database of students electronically. An automated student management Software will manage all personal and academic data of students.
The problem statement provides an outline of the system from user’s perspective. ABC University offers IV-semester MBA programme. This statement has three modules, namely, registration module, examination module, and result generation module.
• Registration module: To be a part of the university, an applicant must be registered, for which the applicant should pay the required registration fee. This fee can be paid through demand draft or cheque drawn from a nationalized bank. After successful registration an enrolment number is allotted to each student, which makes the student eligible to appear in the examination.
• Examination module: The examination of procedure programme comprises of assignments, theory papers, practical papers, and a project.
2. Data Flow Diagram
3. Entity Relationship Diagram
The ER diagram of student admission and examination system
4. Software Requirements Specification Document
The SRS document describes the overall requirements of ABC University to automate the proposed system. This document follows IEEE guidelines for requirements specification document with some variations.
Introduction
This section specifies the overall requirements of the software. The final software will have features according to this document and assumptions for any additional features should be made by individuals involved in developing/ testing/ implementing/ using this product.
(a) Purpose
The requirements specification document determines the capability of the software to be developed. In addition, it specifies constraints required by the system.
(b) Scope
The final software when developed will help the university in registering students and conducting examination. In addition, this will manage the record of the subjects offered in different semesters, the students’ choice of elective papers and the marks obtained by them in different subjects in various semesters.
(c) Definitions, acronyms, and abbreviations
Following abbreviations are used in the entire specification document.
Course: Master in business administration
DB: Database
DBMS: Database management system
RAM: Random access memory
MB: Megabyte
(d) References
University website: Provides information about the course, result, and other
Information.
(e) Overview
The SRS document provides description about the system requirements, interfaces, features, and functionalities.
2. Overall description
The proposed system will maintain information about the students who are enrolled in the MBA programme. In addition, it will manage the record of the subjects taken by the students in different semesters, choice of elective paper and marks obtained by the students in different semesters. In the Ist, IInd, and IIIrd semesters, students have to appear in six theory subjects and three practical papers. It is mandatory to submit a project report in IVth semester, which is followed by viva-voce for the same.
(a) Product perspective
The application will be Windows-based and an independent software application.
(i) System interface
None
(ii) Interface
The application will have a menu screen, which will have the following options:
(iii) Hardware interface
Screen resolutions with minimum of 800 × 600 pixels should be used. It should also support output devices like printer.
(iv) Software interface
software interfaces used for the proposed system are listed below:
(v) Communication interface
None
(vi) Memory constraints
Intel Pentium III processor or higher with a minimum of 128 MB RAM and 600 MB of hard disk space will be required so that software performs its Functions in an optimum manner.
(vii) Operations
The software release will not include automated and maintenance of database.
The university is responsible for manually deleting old/outdated data and managing backup and recovery of data.
(viii) Site adaptations requirements
The terminals at the user’s end will have to support the interfaces (both hardware and software) as mentioned above.
(b) Product functions
The system will allow access only to authorized users like student, administrator
And coordinator depending upon the role. Some of the functions that will be
Performed by the software are listed below:
- Perform modification (by administrator only), such as adding or deleting the marks obtained by the students.
- Provide a printable version of the mark-sheet (result) of the students.
- Use of ‘clear’ function to delete the existing information in the database.
(c) User characteristics
None.
(d) Constraints
(e) Assumptions and dependencies
(f) Apportioning of requirements
Not required.
3. Specific requirements
This section provides the information required by the developers to develop the system.
(a) External interface
This contains complete description of inputs and outputs from the software system.
(b) Functions
None.
(c) Performance requirements
None.
(d) Logical database requirements
The information that will be stored in the database is listed below:
(e) Design constraints
None.
(f) Software system attributes
(i) Security
The application will be password protected and hence, will require users to
Enter their login ID (user name) and password.
(ii) Maintainability
The application will be designed in a manner that it is easy to modify the
Software system later, when required and to incorporate new requirements in the individual modules, such as subject information, marks information, and user accounts.
(iii) Portability
The application will be easily portable on any Windows-based system that
has Oracle 8i installed on it.
4. Change management process
In case the university desires to modify the criteria to select the elective papers or change the number of practical papers in each semester, then the changes will be updated and reflected in SRS document accordingly.
5. Document approvals
When the requirements are gathered according to the user, SRS is then finally reviewed, approved, and signed by the developer and user (university). This SRS serves as a contract for software development activities.
6. Supporting information
None.
The data dictionary for the data stores used in the level 1 DFD can be shown as in Figure below:
