Unit - 2
Software Requirements Analysis & specification
The root of most software systems lies in the needs of those customers. Certain developers build the software framework itself. Finally, the end users can use the finished device. Thus, the consumer, the manufacturer, and the users are three main parties involved in a new system. Somehow, it is important to explain to the developer the specifications for the system that will meet the needs of the customers and the users' concerns.
The problem is that the client does not generally understand the method of software or software creation, and the developer also does not understand the problem and application area of the client. This allows the parties involved in the construction project to have a contact gap. The SRS's fundamental goal is to bridge this communication gap so that they have a common vision of the software being developed.
One of the key benefits of a successful SRS, therefore, is:
● An SRS establishes the basis for agreement between the customer and the supplier on what the software product will perform.
This contractual basis is also formalised into a legal contract between the customer (or the client) and the developer (the supplier). So, the client clearly explains what it wants from the supplier through SRS, and the developer clearly understands what software capabilities to build. A linked, but significant, gain is:
● An SRS provides a reference for validation of the final product/software.
That is, the SRS lets the customer decide whether the programme meets the specifications. Without a proper SRS, there is no way a customer can tell whether what was ordered is the software being delivered, and there is no way the developer can persuade the customer that all the specifications have been met.
For both the customer and the developer to do a comprehensive and rigorous job of understanding and specification of specifications, providing the basis of agreement and validation should be strong enough reasons, but there are other very practical and pressing reasons for making a good SRS.
Studies have shown that during the requirements process, many errors are made. And an error in the SRS will manifest itself in the final method implementing the SRS as an error. Clearly, we must start with a high-quality SRS if we want a high-quality end product that has few errors. We may, in other words, infer that:
● A high-quality SRS is a prerequisite to high-quality product/software.
The prerequisite for high-quality applications is a high-quality SRS.
Finally, the consistency of the SRS influences the project's cost (and schedule). We know that in the SRS, errors will occur. The cost of correcting an error is also known to rise almost exponentially as time progresses. Therefore, by enhancing the standard of specifications, by making less costly defect removals, we will have tremendous savings in the future. And, in other words
● A high-quality SRS reduces the development cost.
Key takeaway:
● Certain developers build the software framework itself.
● The consumer, the manufacturer, and the users are three main parties involved in a new system.
● The SRS's fundamental goal is to bridge this communication gap so that they have a common vision of the software being developed.
Series of steps that must be taken to turn user needs into SRSS
The method must elicit requirements and requirements and clearly define them.
Analysis requires elicitation and is the most complicated one.
Basic activities :
● problem or requirement analysis
● requirement specification
● validation
Requirement Analysis and Elicitation :
It is linked to the different ways of acquiring awareness of the project domain and specifications. Clients, company manuals, current software of the same kind, guidelines and other project stakeholders are included in the various sources of domain knowledge.
Interviews, brainstorming, task analysis, Delphi methodology, prototyping, etc. are the methods used for elicitation requirements. Elicitation does not generate structured requirement models that are understood. Instead, it expands the analyst's domain awareness and thus assists in providing feedback to the next level.
Requirement Specification :
This practise is used to develop structured models of software requirements. All specifications, including both functional and non-functional requirements and limitations, are defined in their entirety by these models. More information about the issue may be needed during the specification, which can again activate the elicitation phase.
ER diagrams, data flow diagrams(DFDs), feature decomposition diagrams(FDDs), data dictionaries, etc. are the models used at this point.
Validation:
After requirement specifications are developed, the requirements mentioned in this
documents 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 -
o Able to be practically implemented
o Should be valid and as per functionality and domain of software
o No ambiguities
o Must be complete
o Should be clearly demonstrated
|
Fig 1: Requirement process
● In above Fig, the overall requirement phase is shown. As shown in the figure, we can go back to the research activity from the specification activity.
● This occurs when certain aspects of the problem are often evaluated and then defined before evaluating and defining other parts.
● In addition, the specification process also reveals weaknesses in the understanding of the problem, thus requiring further review.
● It goes through the validation activity once the specification is completed. This activity may reveal problems in the specification itself, which involve going back to the phase of the specification, or may reveal weaknesses in the problem understanding, which requires going back to the activity of the review.
Key takeaway:
● The process to gather the software requirements from clients, analyse and document them is known as requirement engineering.
● The main goal of requirement engineering is to develop and maintain sophisticated and descriptive ‘System Requirements Specification’ documents.
A specification of software requirements (SRS) is a document that explains what the software is supposed to do and how it is expected to work. It also describes the functionality needed by the product to fulfil the needs of all stakeholders (business, users)
A Software Specifications Specification (SRS) is a document that provides a complete overview of the anticipated performance of the device. It is normally signed off at the conclusion of the engineering process of the specifications.
A standard SRS consists of -
● A purpose - Initially, the main objective is to clarify and illustrate why this document is important and what the intention of the document is.
● An overall description - The product summary is explained here. It's simply a rundown or an overall product analysis.
● Scope of this document - This outlines and demonstrates the overall work and primary goal of the paper and what value it can bring to the consumer. It also provides a summary of the cost of construction and the necessary time.
When embedded in hardware, or when linked to other software, the best SRS documents describe how the software can communicate.
Some of the attractive qualities of an SRS are
1. Correct
2. Complete
3. Unambiguous
4. Verifiable
5. Consistent
6. Ranked for importance and/or stability
- If any requirement included in the SRS reflects anything needed in the final framework, an SRS is right.
- It is complete if the software is expected to do anything and the software's responses to all groups of input data are defined in the SRS.
- It is unambiguous if and only if each specified requirement has one and only one requirement. In natural language, which is fundamentally vague, specifications are also written.
- If and only if every specified condition is verifiable, an SRS is verifiable. A
If there is any cost-effective mechanism that can verify if the final software meets the requirement, the requirement is verifiable.
5. If there is no requirement which conflicts with another, it is consistent. Terminology may trigger inconsistencies; different specifications, for example, can apply to the same object using different words. Logical or temporal contradictions between requirements that trigger inconsistencies can occur. This happens whenever any software device incorporates two or more of the SRS. For instance, suppose a requirement states that before another event f, an event e is to occur.But then another set of specifications states that event f should occur before event e (directly or indirectly by transitivity) before event e. Inconsistencies in an SRS can represent some significant issues.
6. An SRS is graded for significance and/or stability if the criteria for each requirement is the meaning of the requirement and its stability are indicated. The stability of the market reflects the chances that it will improve in the future. This can be expressed in terms of the projected amount of transition. For iterative growth, this understanding of the value each requirement offers is necessary. This assessment is focused on the collection of requirements for an iteration.
Of all these characteristics, completeness is probably the most essential property to create and also the most difficult. Incompleteness is one of the most common shortcomings in design specifications. Missing specifications require additions and adjustments to the specifications later in the development cycle, which are also costly to implement. Incompleteness is also a significant cause of the customer's disagreement with the supplier.
COMPONENTS OF AN SRS:
Some of the device properties that an SRS can define are listed here.
1. Functional requirements
The functional requirements specify what output from the given inputs should be generated. So they simply define the connectivity between the system's input and output. For each practical demand:
- Specify a comprehensive overview of all the data inputs and their origins, the units of measurement and the number of relevant inputs:
- It is important to define all the operations to be performed on the input data to obtain the output, and
- It is important to take care not to specify any algorithms that are not components of the system but may be required to implement the system.
- If the system acts abnormally when some invalid input is given or due to any error during computing, it must clearly state what the system should do. Specifically, the device behaviour for invalid inputs and invalid outputs should be defined.
2. Performance requirements
The performance restrictions on the software system are defined in this section of the SRS. It is important to clearly define all specifications relating to the performance characteristics of the system. For a user event or screen refresh time or a mix of both, performance criteria are usually expressed as processed transaction s per second or response time from the device. It is a good idea for the most used or important transactions, user events and screens to pin down performance criteria.
3. Design constraints
The client environment can prohibit the designer from including some design constraints that need to be met. Standard enforcement, resource limitations, operating environment, reliability and security specifications and policies that could have an impact on the system design are the various design constraints. All such constraints should be defined and specified by an SRS.
Standards compliance : This defines the specifications for the standard to be adopted by the framework. The criteria which include the format of the report and the respective procedures.
Hardware imitations : To run, the programme requires some current or predetermined hardware, thus enforcing design restrictions. Hardware limitations which include the types of machines used to provide memory space for the operating system, etc.
Fault tolerance : The criteria for fault tolerance will impose a significant restriction on the design of the device. Requirements for fault tolerance often make the system more complicated and costly, so they should be reduced.
Security : Security specifications for all types of systems have become important and relevant at the moment. Security standards limit the use of certain commands to manage access to the database, provide various forms of access, require different individuals to access, require the use of passwords and cryptography techniques, and retain a device log of activities.
4. External interface requirements
For the specifications of each external interface:
a. All potential machine encounters with people's hardware and other software should be clearly described.
b. The characteristics of each software product user interface should be defined and
c. Logical features of each interface between the software product and the hardware components for hardware interfacing should be specified by the SRS.
Key takeaway:
● SRS is a document that explains what the software is supposed to do and how it is expected to work.
● For your entire project, a software specification is the foundation.
● The use of the SRS helps ensure fulfilment of specifications.
The fundamental goal of problem analysis is to gain a clear understanding of the needs of consumers and developers, what exactly the programme wants and what the solution constraints are.
1. Divide and conquer
2. State and Projection
3. DFD’S( Data Flow diagrams )
4. ERD’S(Entity Relationship diagram )
- As with every dynamic job, the fundamental concept used in analysis is the same: divide and conquer. That is, divide the issue into subproblems and then try to understand each sub-problem and its relation to other sub-problems in an attempt to understand the overall problem.
- Often the notions of state and projection can also be used effectively in the method of partitioning. Any conditions concerning the system are a condition of a system. Frequently, a machine is first seen as running in one of the states while using state for each state, there are multiple potential states, and then a thorough analysis is carried out. This method is often used in software or process-control software in real time.
- A system is defined from multiple points of view in projection . Although making use of Projection, various system viewpoints are described and from these different perspectives the system is then evaluated. To form the analysis for the complete system, the various "projections" obtained are combined. It is also simpler to evaluate the method from various viewpoints, since it restricts and focuses on the study's reach.
- DFD : It depicts the interaction between data objects and is used to perform data modelling activities. You may use Data Object Description to define the attributes of each object in the Entity Relationship Diagram. It provides the framework for data design-related activities.
- EFD : It shows the functions that transform the flow of data and also shows how information is transformed as it passes from input to output. It provides additional information that is used throughout the study of the field of information and serves as a basis for feature modelling. It also helps the designer to create functional and data domain models at the same time.
Key takeaway:
- The fundamental goal of problem analysis is to gain a clear understanding of the needs of consumers and developers,
- A system is defined from multiple points of view in projection.
- Often the notions of state and projection can also be used effectively in the method of partitioning.
For certain organisations, software validation is also perceived to be daunting. It appears to be a monumental task with all the demands and guidelines stated in the standards and regulations. It is not as difficult as some may believe, however. This tangled web can be streamlined to make it easier to understand and not only satisfy regulatory requirements, but also to act as a valuable business tool.
Validation of requirements is the process of ensuring that the framework that the client really needs is specified by requirements defined for development. We conduct requirement validation to verify problems relevant to specifications.
In order to verify errors at the initial stage of development, we typically use validation criteria as the error will increase excessive rework when found later in the development phase.
While very few in-house software systems are developed, many of the systems used are configurable to meet your business needs. The regulations state that, for their intended use, these configured systems must be checked. Different levels of validation diligence should be conducted, depending on the risk and sophistication of the programme.
Step 1: Create the Validation Plan
In the validation process, the first step is to create a validation plan (VP) that defines who, what, and where. The plan typically consists of a system overview, environmental requirements, expectations, constraints, conditions for testing, approval criteria, identification of the validation team, including individual roles, procedures needed, and documentation required.
Step 2: Define System Requirements
The next step is to identify the system specifications (SRS) that define what you plan to do with the system. These can be broken down into two classifications: specifications for facilities and functional requirements. Infrastructure specifications include the description of the required staff personnel and the necessary facilities and equipment for the assignment.
Technical specifications include topics such as performance requirements, safety requirements, interfaces between systems and users, and the appropriate operating environment. A risk analysis of the system is also important. This study assesses the specifications of the role and identifies any holes. To assess and minimise any threats, the differences are then evaluated.
Step 3: Create the validation Protocol & Test Specification
The testing process starts with the development of a test plan and test cases (VP-Validation Protocol) (Test Specifications). The test plan outlines the software test's goals, scope, strategy, threats, resources, and schedule. It records the methodology that would be used to validate and ensure that the specifications are met by a product or system.
Inputs, behaviour, or events and expected responses are defined in the test cases to decide whether a function of an application performs as appropriate. Since any possible input-output combination can not be tested and businesses are trying to reduce the costs associated with testing, the aim is to find as many defects as possible with as little testing as possible.
Step 4: Testing
It is then able to begin the actual testing. Black box testing (testing that ignores the device or component's internal code and focuses on the software's inputs and outputs) is used for commercial off-shelf systems validation since the code is not owned by you. Based on the test plan and test scenarios, experiments are executed. Any mistakes, faults, anomalies, and deficiencies are reported and recorded in a final report and disposed of.
Step 5: Develop/Revise Procedure & final report
Procedures for device use and management must be developed/revised once testing is completed. Then, a final validation report is developed, checked, and accepted prior to the device being published for use.
Usually, the Final Report or Validation Report (VR) acts as a wrap up validation. The final release for a scheme to go into development is the acceptance of this report. Elements such as where system support can be found, user training, how to handle system stability, and backup and recovery plans should be included in the study. The final report will also contain a test report on the progress of the experiments and the arrangements for any irregularities that may have arisen during the tests.
Key takeaway:
● It is checked for inconsistency, omissions, and uncertainty as each aspect of the requirements model is developed.
● Validation of requirements is the process of ensuring that the framework that the client really needs is specified by requirements defined for development.
● It may also be referred to as software quality control.
References:
- Software Engineering by Jan Sommerville (9th Edition) Pearson
- Software Engineering Principles & Practices by RohitKhuranaITLESL (2nd Edition) Vikas Publishing House Pvt. Ltd.
- Software Engineering Fundamentals – Behforooz & Hudson (Oxford: Indian Edition1st)
