Requirement Analysis Techniques

Requirement Analysis Techniques

13-17 minutes

Requirement Analysis, also known as Requirement Engineering, is the process of defining user expectations for a new software being built or modified. In software engineering, it is sometimes referred to loosely by names such as requirements gathering or requirements capturing. 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. Here are the objectives for performing requirement analysis in the early stage of a software project:

From What to How : Software engineering task bridging the gap between system requirements engineering and software design.

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

• system information (static view)
• function (functional view)
• behavior (dynamic view)

Software Architecture : Model can be translated to data, architectural, and component-level designs.

Iterative and Incremental Process : Expect to do a little bit of design during analysis and a little bit of analysis during design.

What is Requirement?

A software requirement is a capability needed by the user to solve a problem or to achieve an objective. In other words, 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 to develop quality software that meets customers’ real needs on time and within budget.

Perhaps the greatest challenge being faced by software developers is to share the vision of the final product with the customer. 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, or someone will be surprised when it is delivered. Surprises in software are almost never good news.

Therefore, we need ways to accurately capture, interpret, and represent the voice of customers when specifying the requirements for a software product.

Activities for Requirement Analysis

Requirements analysis is critical to the success or failure of a systems or software project. The requirements should be documented, actionable, measurable, testable, traceable, related to identified business needs or opportunities, and defined to a level of detail sufficient for system design. Conceptually, requirements analysis includes four types of activity:

1. Eliciting requirements : the task of communicating with customers and users to determine what their requirements are. This is sometimes also called requirements gathering.
2. Analyzing requirements : determining whether the stated requirements are unclear, incomplete, ambiguous, or contradictory, and then resolving these issues.
3. Requirements modeling : Requirements might be documented in various forms, such as natural-language documents, use cases, user stories, or process specifications.
4. 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 system for feasibility.
• Perform economic and technical analysis.
• Allocate functions to system elements.
• Establish schedule and constraints.
• Create system definitions.

Requirement Analysis Techniques

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, flow-charts,) instead of pages of text.

Once the requirements are gathered, we document the requirements in a Software Requirements Specification (SRS) document, 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.

Business Requirement vs Software Requirements

A business plan or project requires a variety of requirements to help define goals and establish a scope for the work that will be undertaken. Requirements also provide context and objective ways to measure progress and success. Once business requirements are established, software requirements are defined and developed in order to move a project forward.