Requirement analysis in software development lifecycle

Requirement Analysis, also known as Requirement Engineering, is the process of defining user expectations for a new software being built or modified.

In software development life cycle (SLDC) , it is referred to as the requirements gathering stage. Requirements analysis encompasses those tasks that go into determining the needs or conditions to meet for a new or altered product or project, taking account of the possibly conflicting requirements of the various stakeholders, analyzing, documenting, validating, and managing software or system requirements.

In the requirement analysis stage, the following objectives are understood

What needs to be built and how it needs to be done: Software engineering design aims at bridging the gap between system requirements and software design.

3 Orthogonal Views: Provides software designer with a model of:

1. Back end system
2. Functional aspect of the software
3. Behavioral aspect of the software

 

Backend and Data Architecture: Model designed in previous stage can next be translated to data, architectural, and component-level designs.

Iterative and Incremental Process: This helps in planning the cadence of building the blocks identified. This process aids in both product and project management.

What is Requirement?

A software requirement is a capability needed by the user to achieve an objective.

In other words, a requirement is a software capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed documentation.

Ultimately, what we want to achieve is quality software that meets customers’ real needs on time and within budget.

All stakeholders in a project – developers, end-users, software managers, customer managers – must achieve a common understanding of what the product will be and do.

This common understanding is vital to prevent any misunderstanding in the outcome

Thus it behooves that we need ways to accurately capture, interpret, and represent the needs of our business partners/customers when specifying the requirements for a software product.

Activities for Requirement Analysis

Analyzing business requirements is critical to the success or failure of a systems or software project. The requirements captured should be documented, actionable, measurable, testable, traceable, related to identified business needs or opportunities. The requirements are then further defined to a level of detail sufficient for system/module design.

Conceptually, requirements analysis includes four types of activity:

Eliciting requirements: The task of communicating with customers and users to determine what their requirements are. This is sometimes also called requirements gathering. Requirements gatherings are done by sending out questionnaires or by frequent interviews.

Analyzing requirements: Once the requirements are understood, a business analyst, then determines whether the stated requirements are unclear, incomplete, ambiguous, or contradictory, and then proceeds to resolve these issues.

Requirements modeling: Requirements might be documented in various forms, such as natural-language documents, use cases, user stories, or process specifications.

Review and retrospective: Team members reflect on what happened in the iteration and identifies actions for improvement going forward.

Requirements analysis is a team effort that demands a combination of hardware, software, and human factors engineering expertise as well as skills in dealing with people. Here are the main activities involve in requirement analysis:

• Identify customer’s needs.
• Evaluate the system for feasibility.
• Perform economic and technical analysis.
• Allocate functions to system elements.
• Establish schedule and constraints.
• Create system definitions.

Requirement types

Requirement analysis helps organizations to determine the actual needs of stakeholders. At the same time, it enables the development team to communicate with stakeholders in a language they understand (like charts, models, flowcharts) instead of pages of text.

Once the requirements are gathered, it is documented in a Software Requirements document. This document classifies the user’s needs into types of requirements.

These requirements range from very high-level concept-focused to very specific for a part. The main types of requirements are:

Business requirements: These contain statements of goals, objectives, and outcomes that describe why a change has been initiated. They can apply to the whole of an enterprise, a business area, or a specific initiative.

Stake holder Requirements: Describe the needs of stakeholders that must be met in order to achieve the business requirements. They may serve as a bridge between business and solution requirements.

Solution Requirements: Describe the capabilities and qualities of a solution that meets the stakeholder requirements. They provide the appropriate level of detail to allow for the development and implementation of the solution.

Solution requirements can be divided into two sub-categories:

• Functional Requirements: This simply means a task (sometimes called action or activity) that must be accomplished to provide an operational capability. They are basically the requirements stated by the user which one can see directly in the final product.
• NonFunctional Requirements : Are basically the quality constraints that the system must satisfy.They are also called non-behavioral requirements. Interface constraints, Performance constraints: response time, security, storage space,Operating constraints, maintenance, portability, Economic constraints etc. form non functional requirements.

Transition Requirements: Describe the capabilities that the solution must have and the conditions the solution must meet to facilitate transition from the current state to the future state

Other miscellaneous requirements can be classified into:

• Performance Requirements means the extent to which a function must be executed, generally measured in terms such as quantity, accuracy, coverage, timeliness, or readiness.
• System Technical Requirements identifies the way information flows from the front end to the back end.

The analyst can further break the requirements into Use cases or as User Stories, which are shared with the stakeholders for approval.

This document is easy to understand for both normal users and developers. Any changes in the requirements are also documented and go through a change control procedure and finalized on approval.