+91-98108-26291

13 Oct

Software Requirement Analysis

  • 0 Comments

Whenever we talk about the software development, the first point that comes in to the picture is software requirement analysis (SwRA), There have been different terminology used in place of Software Requirement Analysis which can be listed as requirement gathering or we can say requirement elicitation. However each of them have different meaning. Today I am going to put a little bit of my understanding on software requirement analysis.

The purpose of SwRA is to transform the system requirements into software requirement based on which the software is going to be developed or if the scope is only software then Stakeholder requirements into software requirements. It is the process of defining the expectation of the customers, stakeholders or users for an application or software that is going to be developed or modified from existing, SwRA. It is the process of gathering, analyzing, documenting, validating and managing software requirements. Process ID given in Automotive SPICE for Software requirement analysis is SWE.1. Previously, till Automotive SPICE V2.5 all the engineering processes were given the IDs as ENG and SwRA was denoted by ENG.4. But from Automotive SPICE Version 3.0, plug in concept was introduced and System and Software engineering processes were placed in different groups that’s the reason now IDs are divided from ENG to SYS and SWE respectively.

SwRA phase or process plays a vital role in development of software, as the old quote says “the beginning is the most important part of the work”, If you have the correct beginning, and you got the right direction, it will lead to the final product which will satisfy the customer’s, stakeholder’s or user’s expectation, who are going to use it.

 

 

 

SwRA is one of the phase of software development lifecycle and it is carried out by performing a set of activities. In a broader picture, software requirement analysis is carried out by performing the activities shown in above figure.

First comes in identifying the sources of requirement, before identifying the sources, you should be aware of your project scope, a well defined project scope helps a lot, in identifying the requirements for software development as project scope has the information about what comes in project scope and what does not comes in project scope. On the basis of project scope, you should identify the scope of SwRA. Sometimes what happen, if the scope has not been defined appropriately software requirement analyst spend a lot of time in identifying the requirements which later on comes out to be of very low priority or by the time it is being observed that those requirement does not fit in or solve the purpose.

Let us come to the point, sources of requirement can be the following

  1. System Requirements
  2. System Architecture Design
  3. Stakeholder Requirement Specification
  4. Change Request
  5. Project Scope
  6. Customer, Stakeholders
  7. Internal Teams
  8. Higher Management

 

Once you are done with the identification of sources, you need to specify or narrow down the no. of stakeholders from whom you are going to accept the requirements, lets supoose you are developing a software, and you are getting the requirement from every one involved in the project from customer end, it would land in a big hustle, which will arise in conflict of requirement, ofcourse there will be conflict in requirement later on as well which is supposed to be resolved, but here if everyone involved will give the requirement, it will be difficult to maintain and fulfil their wishes, so first of all designate a SPOC who will be responsible for sharing the requirements, which will add one more filter.

Once identification of sources is completed, requirement gathering comes in to the picture, there are various technique which can be used to gather or elicit requirement from the sources

 

  1. Interviews
  2. Meetings
  3. Brainstorming session
  4. Use Cases
  5. Scenarios
  6. Prototyping

 

Ideally requirement gathering is a phase, which let us know, what is the software is supposed to do, what should it not do, how well should it perform and in what environment or conditions. Communication is a key of gathering the requirement, you should be communicating to the stakeholders on a regular basis to be clear on the requirements.

 

When the requirement gathering activity is completed, you should be analyzing the requirement, Analyzing the requirement is the most important step in SwRA, as analyzing is the one, which let us know if the requirement gathered will help us in shaping the software that is going to be developed. Analyzing the requirement is composed of below tasks

 

  1. Check on the feasibility of requirements
  2. Classifying the requirements
  3. Prioritizing the requirements
  4. Impact on operating environment
  5. Impact on change requests
  6. Impact on the project

 

Feasibility study of the requirement outline the practical implementation possibility of the requirement, Various aspects when considering feasibility is technical feasibility, economic feasibility, resource feasibility etc.

When talking about the classification and prioritization of the requirement, the point is to classify the requirement based on their traits or attribute, there are 2 broad categories in which the requirements are classified, one is functional requirement and other one is non-functional requirement. Prioritization of the requirement is also one necessary step that should be considered when talking about the analysis of requirements. Those requirement which defines the major functionality of the software should be given top priority, Prioritizing the requirement also helps in resolving the conflict between the requirements.

When we are talking about the impact on operating environment, the basic thing which is checked is the RAM, ROM, EEPROM, Flash memory usage etc, however there are additional things which are also supposed to be checked like interfaces, overall performance etc

Then analyzing the impact on change requests and project, you should be aware if the new requirement introduced is already being developed in any other change request or project or if there is any kind of dependencies in the set of requirements in other change requests or project.

When analyzing the software requirement, there is one more important step that should be considered and that is if the requirement gathered are testable, development of verification criteria. Because if the requirements can not be tested, how you are supposed to say that the given requirement is fulfilled.

Now after analyzing, let us talk about documenting the requirements, when we talk about documenting or formalizing the requirement, the first thing that comes in the mind is software requirement specification (SRS). In simple words a SRS is a document which gives the description of the software that is to be developed. SRS forms the basis of an agreement between customers and suppliers on how the software would function. If developed and used appropriately SRS can help in preventing the project failure. If developed properly, SRS helps in getting the realistic estimates of costs, schedule and risks. The major goals which are fulfilled by SRS are mentioned below:

 

  1. Elaborating the scope of work in such a way, that it can be very well understood by software development team
  2. Providing a base to test team to develop the test cases
  3. Providing the basis of accepting the software when development and testing is completed

 

SRS should at least, contain the below aspects

  1. Introduction -  which will have purpose of documentation, a brief of the software which is going to be developed and intended audience
  2. Overall description – which will have the description of software features, then history of software ie. Version details, designing or implementation constraint, and dependencies or assumptions
  3. Software Feature – which will have all the feature of the software described in detail, then description of functional requirements with their priorities, along with the verification criteria.
  4. Non-Functional Requirements – A dedicated section for the description of all the non-fucntional requirements which are to be considered when developing the software along with their verification criteria which may include use cases
  5. Interface Requirement – which will have requirements for all the interfaces (external & internal) to whom the software is going to interact, it may be user interface, hardware interface or software interface
  6. Other Requirement – If there are any other requirement, which are not covered in the above sections

 

There are few charateristics or principle that should be followed while developing the SRS

  1. Clear and Correct
  2. Consistent and coherent
  3. Modifiable and Verifiable
  4. Prioritized and Unambiguous
  5. Traceable

 

Once the documenting is completed, it should be verified or we can say validated, Validating the requirement, Validating the requirement means verifying and approving the SRS. Conduct a review meeting with customer for the validation of requirement, Review can take place by performing inspection, walk through by using SRS review checklist. During the verification and validation activity there are sevaral input which are given by all the participants of the review meeting, once they are mutually agreed, then those input are to be incorporated in the SRS and if needed review should be conducted again. And after this final sign off from the customer and stakeholder having the authorities to approve the SRS. There are few points which are to be considered when validating the requirements

 

  1. If they can be practically implemented
  2. If they are valid and as per functionality and domain of software
  3. If there are any ambiguities
  4. If they are complete
  5. If they can be demonstrated

 

However, if you look at the above points, they are almost covered while analyzing the requirements, it’s just that they analysis points can be re-reviewed if required when validating the requirements.

Then comes in traceability, I have explained, what is traceability, types of traceability and importance of traceability in my previous blogs, so when we talk about the traceability in SwRA phase, it is just that bidirectional traceability should be established between system requirements and software requirements and also between elements of system architecture design and software requirements by developing a traceability matrix.

With this I sum up this blog, please share your views, comments, remarks on this and also if you have any ideas on the topic for the next blog.