Requirements Management

Software Requirements

Software Requirements is a field within Software Engineering that depicts of a system’s features and functionality. Software Requirements may range from a high level abstract statement of a system to a detailed functional specification.

Requirements Engineering

Requirements Engineering is a complex process in which only writing down customer’s requirements does not fulfill the purpose instead customer’s requirements must be understood correctly being flexible at the same time. Flexibility implies having a process for the requirements development and incorporating updated requirements asper our understanding. Today, the most basic problem of a business is that the requirements are dynamic in nature and change with time along with our understanding of the problem.

Requirements are important and requirements planning to define requirements strategy and activities must be incorporated in order to achieve project success rate.

Requirements and Requirements’ Importance

A requirement is defined as an attribute in a system, a statement that identifies the system’s characteristic and capability that enables the system to be usable and be of a value to the user. Requirements are important as they are the basic elements for the development of any system or a product. The development of any system will start only when the requirements are set for the project and once it is finalized.

The right approach demands to invest enough time in requirements gathering, analysis and management activities. Stated requirements are different than the real requirements and stated requirements are provided by the customer in the beginning in the form of a proposal or a statement of work. Stated requirements are analyzed properly and converted into real requirements based on the customer’s needs and expectations to deliver the final product.

Requirements Activities

Requirements activities primarily consists of requirements gathering and requirements change management throughout the system development life cycle. There are other requirement activities that include:

• Stakeholders Identification

This includes a person who is interested in a system or a product that meets particular requirement of a business. Identifying stakeholders is the first step in requirements activities and this includes identifying all the stakeholders in the project and their positive/negative influences on the project.

• Understanding Customer’s Needs and Expectations

This is also known as requirements elicitation. This includes understanding the customer’s needs and expectations of a particular system.

• Requirements Identification and clarification

This includes expressing requirements in a simple form. Business requirements are the most important activities of an organization and are identified from business objectives. Business scenarios are one of the useful techniques that are used to identify and understand business requirements. Once the business requirements are identified, requirements clarification is done to make sure that these requirements clearly explain the customer’s needs and understood by the technology teams.

• Requirements Definition and Analysis

The requirements must be defined clearly to all the stakeholders in the same manner to make sure that they all are on the same page. Different stakeholder groups have different perspective and understanding of the system’s requirements. This needs to invest a significant time and effort to help the stakeholders achieve a common understanding of the requirements. Once the requirements are defined, requirements analysis is done to make sure that the requirements are well defined fulfills the good requirement criteria.

Criteria of A Good Requirement

• Necessary
• Feasible
• Correct
• Concise
• Unambiguous
• Complete
• Consistent
• Verifiable
• Traceable
• Allocated
• Design Independent
• Non-redundant

• Requirements Specification and Prioritization

This includes explaining each requirement in detail to be accommodated in a specification document based on the project size. Once the requirements are specified, each requirement is prioritized based on its importance. Each requirement has its own importance and level of criticality depending on which the requirements are given priority status such as High, Medium, Low. Once prioritized, the high priority requirements are addressed at first and the lower priority requirements are addressed next.

• Requirements Allocation and Tracking

This includes requirements allocation to different sub systems and system components and requirements tracking. Requirements are needed to be tracked to make sure that each requirement of the system has been addressed. Requirements tracking is mostly done using automated requirements tracking tools. 

• Requirements Management

This includes adding, modifying and removing requirements during different phases of project life cycle. The objective of requirements management is to make sure that an organization’s customer’s and stakeholder’s needs are met, documented and validated. Requirements management starts with the requirements elicitation and analysis and then further includes the planning and integration of the requirements. Requirements management also focuses on the communication between project team members and stakeholders.

• Requirements Testing and Validation

This includes testing the requirements once it is ready and verify that the requirements are fully functional and meet the criteria. Once it is done, requirements are validated to ensure that the real requirements are implemented in the system. 

Requirement Gathering

Gathering requirements is needed when there is a request from an internal or external customer to develop a new system. Requests are in the various forms such as Request for Proposal (), Statement of Work (), an informal or formal inquiry etc. Once a request is received, the requirements gathering activities get started. During the requirement gathering process, too much time and efforts are invested in project initial phase due to the following reasons:

• The project is in the initial phase and requirements are not clear.
• No road map or checklist is prepared for the requirement gathering process.
• Resources are not available and no commitment for the project deliverable in the beginning as the project is just getting started.
• The customer and other users are still in the process of getting prepared for the project.
• The team who will be working on the project development, still do not have the clear picture of the customer’s objective and expectations.

So, if the requirements gathering process is not effective, a lot of efforts and time get wasted during the actual development of the project as a result of poorly captured requirements. Thus, a Requirement Analyst comes into picture and plays an important role in performing requirements gathering activities. A Requirement Analyst ensures the project stability by recommending best practices, methods and tools to assist customer, Project Manager and various teams of the project. A Requirements Analyst plays different roles during a project execution, which include:

• Identifying the real requirements of the proposed system by working collaboratively with customer, system architects and designers.
• Managing new and changing requirements to make sure that the project stays under control.
• Suggesting best methods, tools and techniques to the customer to support requirements gathering activities.
• Measuring, tracking and gathering requirements gathering activities.
• Being aware of new technologies.
• Organizing discussions to mediate conflicts.

Types of Requirements

The BABOK defines requirement types as below:

• Business Requirements

Business requirements are the main reason to develop a new system or a software in an organization. Business requirements are identified from the organization goals. Business requirements are referred to the high level statements that outline the objective of a business or an organization. Business requirements define multiple aspects of a business that include:

• WHAT does a business want to accomplish?
• WHY does a project need to be initiated with its solution implemented?
• Metrics used for measuring success

• Stakeholder Requirements

In stakeholder requirements needs of a particular group of stakeholders are identified and defined. There are some important aspects about stakeholder requirements that include:

• WHAT is the need of a particular stakeholder or a stakeholder group, that is defined by stakeholder requirements?
• Various use cases are identified by stakeholder requirements.
• Stakeholder requirements also serve as a connect between the business and solution requirements.

• Solution Requirements

Solution requirements explain the solution characteristics that a solution will consist of to meet the business and stakeholder requirements. There are some key points to be considered about the solution requirements that include:

• WHAT characteristics will be supported by the solution, is described by the solution requirements.
• The solution requirements also describe HOW the solution requirements will satisfy the stakeholder needs from a stakeholder’s point of view.

Solution requirements are divided into the following categories: 

• Functional Requirements

Functional requirements are an integral part of the real requirements. Functional requirements describe what a system or a software must perform. Functional requirements are also referred as behavioral requirements as the inputs/outputs to and from the system are specified in the functional requirements and these requirements specify the behavioral relation between inputs/outputs. Functional requirements are written in a document and the document in which functional requirements are specified is known as Functional Requirement Document (FRD) or Functional Requirement Specification (FRS).

• Non-functional Requirements

Non-functional requirements include system properties and solution qualities are defined by non-functional requirements. Non-functional requirements describe under what environmental conditions the solution will remain most effective and efficient.

• Transition Requirements

The solution characteristics that are required for a solution to transition from the current state to the desired future state, are defined by the transition requirements. Once the transition is over, the solution characteristics are no longer needed. Transition requirements are temporary and insists on change management processes.

There are some additional requirement types that may include:

• Architecture and Design Requirements

Architecture and Design requirements are easy and simple to capture as they are already finalized. These requirements are precise and more detailed as compared to the business requirements. The use cases and design layout are not of a concern; however, all the functionalities need to be analyzed thoroughly in a given use case.

• System Integrated Requirements

System integrated requirements are the low level requirements in which integration takes place into the system. In these requirements each system use case is explained in detail. The system integration team need not review the existing code/functionality, but they must be aware of each functionality in the system. 

• High Level Requirements

High level requirements are also known as the system level requirements that enable defining the system scope and estimating efforts and time to develop the whole system. High level requirements capture customer’s vision and are considered of utmost importance.

• Derived Requirements

Derived requirements are the requirements that are further described and detailed from the high level requirements.

Best Practices for Requirements Development and Management

Basically the best practices for requirements development and management are grouped together into the following three categories:

• Requirements Development
• Requirements Management
• Project Management

The best practices include the following:

• Requirements plan development.
• Requirements meeting the good requirement criteria.
• Involvement of all the stakeholders in the project.
• Project objectives must be identified, documented clearly and agreed upon by the stakeholders.
• Requirements workshops to attain diversified vision and get the acceptance of all the stakeholders.
• Provide training on requirements to the requirements analysts, team members and the stakeholders.
• Participate in requirements discussions with the stakeholders to identify the real requirements from the stated requirements.
• Ensure that the analysis for each requirement is documented.
• Facilitate the use of effective and efficient requirements gathering techniques and tools.
• Encourage the involvement of customer as well as all the team members throughout the development of the project.
• Requirements decisions should be avoided.
• Use of a project glossary and acronyms is advisable.
• Repeat requirements and architecture cycles to attain better requirements and powerful architecture.
• Make use of Subject Matter Experts who have expertise in specific domains and systems.
• Try to keep the requirements to a minimum that meets the needs and expectations.
• Prioritize requirements as early as possible and provide reviews of all requirements related documents.
• Control the changes in requirements and new requirements addition constantly.
• Make the customer be available with additional budget and schedule for additional requirements to complete the project
• Include various versions and releases of product to accommodate new and changed requirements.
• Make use of automated requirements tool and proven requirements methods, practices, tools and techniques.
• Have an approved objective of the project and write a project scope document.
• Meeting rules must be described for all team members explaining how they interact with each other.
• A set of directions must be outlined for effective meetings and emailing.
• Risk assessment should be done for new and changing requirements.
• Manage teams effectively.