When a customer approaches an organization to develop a desired product, they come up with a clear idea of what functions the software should perform and what functions are expected of the software.
Referring to this information, analysts study in detail whether the development of the desired system and its functionality is possible.
This feasibility study is focused on the objectives of the organization. This study analyzes whether a software product can be practically materialized in terms of implementation, the contribution of the project to the organization, cost constraints, and in accordance with the values and goals of the organization. It addresses the technical aspects of the design and product, such as usability, maintainability, performance, and integration.
The output of this phase should be a feasibility study report that should provide adequate comments and recommendations to management as to whether the project should proceed.
Gathering Requirements
If the feasibility study is positive about project execution, the next step begins with collecting requirements from the user. Analysts and engineers communicate with the client and end users to get their ideas about what the software should provide and what features they want to include in the software.
Software requirements specification
The SRS is a document created by a systems analyst after collecting requirements from various stakeholders.
The SRS defines how the intended software will interact with the hardware, external interfaces, speed of operation, system response time, software portability across platforms, maintainability, failover rate, security, quality, limitations, etc.
The requirements received from the client are written in natural language. It is the responsibility of the systems analyst to document the requirements in technical language so that they can be understood and useful to the software development team.
SRS should come up with the following features:
User requirements are expressed in natural language.
The technical requirements are expressed in a structured language that is used internally by the organization.
Design description should be written in pseudocode.
Form format and GUI printing.
Conventional and mathematical notation for DFD etc.
Checking software requirements
After the requirements specifications are developed, the requirements mentioned in this document are validated. The user may ask for an illegal, impractical solution, or the experts may misinterpret the requirements. This results in a huge increase in value if not nipped in the bud. Requirements can be checked against the following conditions −
If they can be practically implemented
If they are valid and according to the functionality and scope of the software
If there are any ambiguities
If they are completed
If they can be shown
Requirements Identification Process
The process of requirements identification can be depicted using the following diagram:
Requirements Identification Process
Requirements Gathering − Developers discuss with the client and end users and know their expectations from the software.
Organization of Requirements – Developers prioritize and distribute requirements in order of importance, urgency, and convenience.
Negotiation and discussion – if the requirements are ambiguous or if there are any contradictions in the requirements of various stakeholders, if any, then this is discussed and discussed with the interested parties. Requirements can then be prioritized and intelligently compromised.
Requirements come from various stakeholders. To eliminate ambiguity and conflicts, they are discussed for clarity and correctness. Unrealistic claims are intelligently compromised.
Documentation. All formal and informal, functional and non-functional requirements are documented and made available for further processing.
Negotiation and discussion – if the requirements are ambiguous or if there are any contradictions in the requirements of various stakeholders, if any, then this is discussed and discussed with the interested parties. Requirements can then be prioritized and intelligently compromised.
Requirements come from various stakeholders. To eliminate ambiguity and conflicts, they are discussed for clarity and correctness. Unrealistic claims are intelligently compromised.
Requirements Identification Methods
Requirements Identification Methods
Requirements elicitation is the process of ascertaining the requirements for a proposed software system by communicating with the client, end users, system users, and others who have an interest in developing the software system.
There are different ways to define requirements
Interview
Interviews are a strong medium for gathering requirements. An organization may conduct several types of interviews, such as:
Structured (closed) interviews, in which every information to be collected is determined in advance, they strictly follow the template and subject matter.
Unstructured (open) interviews, where the information to be collected is not determined in advance, is more flexible and less biased.
Oral interviews
Written interviews
Individual interviews that are conducted between two people at a table.
Group interviews that are conducted between groups of participants. They help to identify any missing requirements as multiple people are involved.
Reviews
The organization may conduct surveys among various stakeholders, inquiring about their expectations and requirements from the future system.
Questionnaire
A document with a pre-defined set of objective questions and corresponding options is given to all interested parties for a response, which is collected and compiled.
The downside of this method is that if a question is not listed on the questionnaire, the issue may be left unaddressed.
Task Analysis
The engineering and development team can review the work that requires the new system. If the client already has some software to perform a certain operation, it is studied and the requirements of the proposed system are collected.