2️Software Requirement Specification (SRS)
1. Requirement Analysis
The hardest part of building a software is deciding precisely what is to be built. Requirement engineering is the disciplined application of proven principle, methods, tools and notations to describe a proposed system’s intended behaviour and its associated constraints.
2. Difficulties of Requirement Engineering
--> Requirements are difficult to uncover: no one give the complete requirement in the first time, if someone does then also requirement are incomplete.
--> Requirement Changes: with the development process requirements get added and changed as the user begins to understand the system and his or her real need.
--> Tight project schedule: have insufficient time to do a decent job.
--> Communication Barrier: user and developer have different technical background and tastes.
--> Lack of resources: there may not be enough resources to build software that can do everything the customer wants.
Types of requirements
Known requirement: Which is already known to the stake holder
Unknown Requirement: Forgotten by stake holder because that are not needed right now
Undreamt Requirement: Stakeholder is unable to think of new requirement due to limited domain knowledge
3. There are majorly four steps in requirement analysis
---> Requirement Elicitation: Gathering of Requirement.
---> Requirement Analysis: Requirements are analysed to identify inconsistences, defects etc and to resolve conflict.
---> Requirement documentation: Here we document all the refined requirement properly.
---> Requirement Review: Review is carried out to improve the quality of the SRS
3.1 Methods of Requirement Elicitation
Is the most difficult, most critical, most error-prone and communication intensive aspect of the s/w development. It can only succeed only through an effective customer developer partnership.
--> Interview
Both parties would like to understand each other
Interview can be of two types open-ended or structured
In open ended, there is no present agenda, context free questions can be asked to understand the problem, to have an overview over the situation.
In structured interview, agenda is pre-set.
--> Brain Storming
A kind of group discussion, which lead to ideas very quickly and help to promote creative thinking
Very popular now a days and is being used in most of the organizations
All participants are encouraged to say whatever idea come to their mind and no one will be criticized for any idea no matter how goofy it seems
--> Delphi technique
Here participants are made to write the requirement on a piece of paper, then these requirements are exchanged among participants who gave their comments to get a revised set of requirements. This process is repeated till the final consensus is reached.
--> FAST (facilitated application specification technique)
This approach encourages the creation of joint team of customer and developer who works together to understand correct set of requirements.
Everyone is asked to prepare a list of — What surrounds the system — Produced by the system — Used by the system — List of service, constraints, and performance criterion — Then we divide these lists into smaller list to work in smaller teams
--> QFD (quality functional deployment)
Its emphases to incorporate the voice of the customer with importance
Then according to customer, a value indicating a degree of importance, is assigned to each requirement. Thus, the customer, determine the importance of each requirement on a scale of 1 to 5 as: — 5 point: very important — 4 point: important — 3 point: not important but nice to have — 2 point: not important — 1 point: unrealistic, requires further explanation
3.2 Methods of Requirement Analysis
In this phase we analysis all the set of requirements to find any inconsistency or conflicts. In requirement gathering phase our all concentration was on getting all the set of requirements but now, we see how many requirements are contradictory to each other or requires further exploration to be considered further.
Different tools can be used Data flow diagram, Control flow diagram, ER diagram etc
--> Data Flow Diagram
A data flow diagram or bubble chart is a graphical representation of the flow of data through a system. It clarifies systems requirements and identify major transformations.
DFD represent a system at different level of abstraction. DFD may be Partitioned into levels that represent increasing information flow and functional details.
Components of DFD — Function/Process — Data Store — External Entity — Data Flow
DFD uses hierarchy to maintain transparency thus multilevel DFD’s can be created. Levels of DFD are as follows:
0-level DFD: t represents the entire system as a single bubble and provides an overall picture of the system.
1-level DFD: It represents the main functions of the system and how they interact with each other.
2-level DFD: It represents the processes within each function of the system and how they interact with each other.
Control Flow Diagram/Control flow chart/Flow Chart
— A flow chart is a graphical representation of how control flow during the execution of a program. It use the following symbols to represent a system’s control flow.
Introduction 1.1 Purpose 1.2 Scope/Intended Audience 1.3 Definition, Acronyms and Abbreviation 1.4 References / Contact Information / SRS team 1.5 Overview
Overall Description 2.1 Product Perspective 2.2 Product Functions 2.3 User Characteristics 2.4 General Constraints 2.5 Assumptions and dependencies
Specific Requirement 3.1-External interface requirements (user/hardware/software interface) 3.2-Functional requirements 3.3-Performance requirements 3.4-Design constraints (Standards compliance/hardware limitations) 3.5-Logical database requirements 3.6-Software system attributes (Reliability, availability, Security, Maintainability)
Change Management process
Document approval 5.1-Tables, diagrams, and flowcharts 5.2-Appendices 5.3-Index
3.4 Requirement Review
Before finalising the requirement one more review specially by a third party, who a master in the industry is advisable, to have a fresh look over the system, and can mentions any points if missed by team.
4. Software Quality Assurance (SQA)
Definition: SQA is a process ensuring software products meet quality standards and requirements.
Objective: Prevent defects, improve quality, and ensure customer satisfaction.
Process: Implements quality control and management activities throughout development.
Techniques: Uses code reviews, inspections, audits, and testing to evaluate software quality.
Standards: Adheres to international standards like ISO 9001, IEEE 730, and CMMI.
Quality Attributes: Focuses on reliability, maintainability, usability, efficiency, and functionality.
Continuous Improvement: Monitors processes and products to identify and implement improvements.
Metrics: Employs metrics like defect density and code coverage to evaluate quality.
Training: Emphasizes skill development for developers and testers to meet quality standards.
Documentation: Requires proper documentation for transparency and traceability.
4.2 Verification/White Box
Verification ensures that the software product is designed and developed according to the specified requirements and standards. “Are we building the product right”.
Process of Ensuring that the product meets its design specifications.
Focuses on static analysis techniques. Checks for consistency, completeness, and correctness. — Code reviews — Static analysis tools — Inspection of requirements, design, and code documentation
4.3 Validation/Black Box
Validation ensures that the software product meets the end-user requirements and is fit for its intended purpose, “Are we Building the right product”. Ensures that the product meets its design specifications.
Focuses on static analysis techniques. Checks for consistency, completeness, and correctness. — Code reviews — Static analysis tools — Inspection of requirements, design, and code documentation
----------------------
5.2 Benefits of ISO 9000 in Software Engineering
Improved customer satisfaction
Enhanced process efficiency and effectiveness
Reduced risk of software failures and defects
Increased marketability and competitiveness
5.3 Implementation Steps for ISO 9000 in Software Engineering
Obtain top management commitment
Establish a quality management system
Train and educate employees
Document processes, procedures, and policies
Monitor, measure, and analyze processes
Implement improvements and corrective actions
Conduct internal audits
Seek third-party certification (ISO 9001)
6 Capability Maturity Model
CMM is a strategy for improving the software process, to generate quality software.
The Capability Maturity Model (CMM) is a development model created after a study of data collected from organizations that contracted with the U.S. Department of Defence, who funded the research. The term "maturity" relates to the degree of formality and optimization of processes, from ad hoc practices, to formally defined steps, to managed result metrics, to active optimization of the processes.
It is use to judge the maturity of s/w process an organization and to identify the key practise that are required to increase the maturity of theses process. There are five levels of the CMM.
---> Initial (process unpredictable and poorly controlled)
No engineering management, everything done on ad hoc basis.
Software process is unpredictable with respect to time and cost.
It depends on current staff, as staff change so does the process.
---> Repeatable (basic project management)
Planning and managing of new projects are based on the experience with the similar projects.
Realistic plans based on the performance based on the previous projects.
---> Defined (process standardization)
Process of developing and maintaining s/w across the organization is documented including engineering and management.
Training programs are implemented to ensure that the staff have skills and knowledge required.
Risk management.
---> Managed (Quantitative measurement)
Organization set quantitative goals for both product and process.
Here process is predictable both with respect to time and cost.
---> Optimized (continuous process improvement)
Here organization analysis defects to determine their causes and goals is to preventing the occurrence of defects.
Here company continuously improve the process performance of their project.
Last updated