Planning Good Requirements
So, what makes a good requirement? A good requirement should be valuable and actionable; it should define a need as well as provide a pathway to a solution. Everyone on the team should understand what it means. Requirements vary in complexity.
A good Requirements Document can be part of a group with high-level requirements broken down into subrequirements.
They may also include very detailed specifications that include a set of functional requirements describing the behavior or components of the endproduct.
Good requirements need to be concise and specific, and should answer the question, “what do we need?” Rather than, “how do we fulfil a need?”
Good requirements ensure that all stakeholders understand their part of the plan; if parts are unclear or misinterpreted the final product could be defective or fail.
Preventing failure or misinterpretation of requirements can be aided by receiving feedback from the team continuously throughout the process as requirements evolve. Continuous collaboration and buy-in with everyone is a key to success.
Requirement Gathering and Analysis
A requirement is a condition or capability needed by a stakeholder to solve a problem or achieve an organizational objective; a condition or capability that must be met or possessed by a system.
Requirement analysis in software engineering covers those tasks that go into determining the needs or conditions to meet for a new or altered product taking account of the possible conflicting requirements of various stakeholders, analyzing, documenting, validating and managing software or system requirements.
The requirements should be −
- Documented
- Actionable
- Measurable
- Testable
- Traceable
Requirements should be related to identified business needs or opportunities, and defined to a level of detail sufficient for system design.
A Business analyst gathers information through observing the existing systems, studying the existing procedures, discussions with the customers and the end users. The analyst should also have imaginative and creative skills in absence of a working System. Analyzing the gathered requirement to find the missing links is requirement analysis.
Eliciting Approach
To elicit the objectives, ask the business expert, the development manager, and the project sponsor the following questions −
What business objectives of the company will this project help achieve?
Why are we doing this project now?
What will happen if we do it later?
What if we do not do it at all?
Who will benefit from this project?
Do the people who will benefit from it consider it the most important improvement that can possibly be made at this time?
Should we be doing a different project instead?
Possible objectives might be reducing costs, improving the customer service, simplifying the work flow, replacing obsolete technology, piloting a new technology, and many others. Also, make sure you understand exactly how the proposed project will help accomplish the stated objective.
Different Types of Requirements
The most common types of requirement which a Business analyst is interested would be the following −
Business Requirements
Business requirements are the critical activities of an enterprise that must be performed to meet the organizational objectives while remaining solution independent. A business requirements document (BRD) details the business solution for a project including the documentation of customer needs and expectations.
User Requirements
User requirements should specify the specific requirements which the user expects/wants from software to be constructed from the software project. A user requirement should be Verifiable, Clear and concise, Complete, Consistent, Traceable, Viable.
The user requirements document (URD) or user requirements specification is a document usually used in software engineering that specifies what the user expects the software to be able to do.
System Requirements
System requirements deal with defining software resources requirements and prerequisites that needs to be installed on a computer to provide optimal functioning of an application.
Functional Requirements
Functional requirements capture and specify specific intended behavior of the system being developed. They define things such as system calculations, data manipulation and processing, user interface and interaction with the application, and other specific functionality that show how user requirements are satisfied. Assign a unique ID number to each requirement.
Non-Functional Requirements
Non-functional requirement is the one which specifies criteria that can be used to judge the operation of a system rather than specific behaviors. System architecture speaks on the plan for implementing non-functional requirements.
Non-functional requirements speak on how the system should look like or it can be mentioned like “system shall be”. Non-functional requirements are called as qualities of the system.
Transition Requirements
Transition Requirements describe capabilities that the solution must fulfill in order to facilitate transition from the current state of the enterprise to a desired future state, but that will not be needed once that transition is complete.
They are differentiated from other requirements types, because they are always temporary in nature and because they cannot be developed until both an existing and new solution is defined. They typically cover data conversion from existing systems, skill gaps that must be addressed, and other related changes to reach the desired future state. They are developed and defined through solution assessment and validation.
Traceability and Change Management
Requirements traceability is a way to organize, document and keep track of all your requirements from initial idea generation through to the testing phase.
The requirements trace ability matrix (RTM) provides a method for tracking the functional requirements and their implementation through the development process. Each requirement is included in the matrix along with its associated section number.
As the project progresses, the RIM is updated to reflect each requirement’s status. When the product is ready for system testing, the matrix lists each requirement, what product component addresses it, and what test verifies that it is correctly implemented
Include columns for each of the following in the RTM −
- Requirement description
- Requirement reference in FRD
- Verification Method
- Requirement reference in Test Plan
Example − Connecting the dots to identify the relationships between items within your project. It is a connector of common downstream flow.
Idea Requirements Design Test Business Objectives
You should be able to trace each of your requirements back to its original business objective.
By tracing requirements, you are able to identify the ripple effect changes have, see if a requirement has been completed and whether it’s being tested properly. Traceability and change management provides managers peace of mind and the visibility needed to anticipate issues and ensure continuous quality.
Quality Assurance
Getting requirements delivered right the first time can mean better quality, faster development cycles and higher customer satisfaction with the product. Requirements management not only helps you get it right, but also helps your team save money and many headaches throughout the development process.
Concise, specific requirements can help you detect and fix problems early, rather than later when it is much more expensive to fix. In addition, it can cost up to 100 times more to correct a defect later in the development process after it’s been coded, than it is to correct early on while a requirement.
By integrating requirements management into your quality assurance process, you can help your team increase efficiency and eliminate rework. Moreover, rework is where most of the cost issues occur.
In other words, development teams are wasting majority of their budgets on efforts that are not performed correctly the first time. For example, a developer codes a feature based on an old specification document, only to learn later, that the requirements for that feature changed. These types of issues can be avoided with effective requirements management best practices.
In summary, requirements management can sound like a complex discipline, but when you boil it down to a simple concept – it’s about helping teams answer the question, “Does everyone understand what we’re building and why?” From the business analysts, product managers and project leaders to the developers, QA managers and testers, along with the stakeholders and customers involved – so often the root cause of project failure is a misunderstanding of the scope of the project.
When everyone is collaborating, and has full context and visibility to the discussions, decisions and changes involved with the requirements throughout the lifecycle of the project, that is when success happens consistently and you maintain continuous quality. In addition, the process is smoother with less friction and frustration along the way for everyone involved.
Note − Research has shown that project teams can eliminate 50-80% of project defects by effectively managing requirements. According to the Carnegie Mellon software engineering institute, “60-80 percent of the cost of software development is in rework.”
Obtaining Requirements Signoff
Requirements signoff formalizes agreement by project stakeholders that the content and presentation of the requirements, as documented, are accurate and complete. Formal agreement reduces the risk that, during or subsequent to implementation, a stakeholder will introduce a new (previously unencountered) requirement.
Obtaining requirements signoff typically involves a face-to-face final review of requirements, as documented, with each project stakeholder. At the end each review, the stakeholder is asked to formally approve the reviewed requirements document. This approval may be recorded either physically or electronically.
Obtaining requirements signoff is typically the final task within Requirements Communication. The Business Analyst will require the output from the Formal Requirements Review(s), including accommodation of any comments or objections which were raised during the review process.
