Managing Your Requirements 101 – A Refresher Part 2: How to write good requirements and types of requirements
VijaySankar 270000E5JQ Comments (4) Visits (41343)
This is the second post in our series – Managing Your Requirements 101 – A Refresher. Read the first part here.
Requirements are the starting point for everything - project scoping, cost estimation, scheduling, coding, testing, and release management. If the requirements captured doesn’t serve the purpose that are supposed to do; there is hardly any benefit in spending time and money behind it. I remember in Innovate 2012 at Orlando, Arnold Flores from Raytheon speaking about five common traps that results in ineffective and non-verifiable defects - Not understanding requirements, Not having continuous dialogue with stakeholders, Not getting consensus, Not involving other disciplines early and Not limiting scope and requirements creep. Thus good quality requirements should
So how to get the right requirements and make sure they are of quality ones. Some of the official channels that Business Analyst try to get requirements of a client could be interaction with end users or sponsors, business cases, request for proposals, regulations and so on. In a seminal article titled Writing good requirements is a lot like writing good code , Jim Heuman, a Requirements Management evangelist talks in detail about how to write good quality requirements. A lot of articles are available in public domain that talks about how to write good requirements. Essentially the core principles revolve around a requirement being Simple, Verifiable, Necessary, Achievable, and Traceable. We will discuss some of the techniques used to capture requirements later. Provided below are some of the resources that will help you in writing good requirements.
Writing good requirements is a lot like writing good code by Jim Heumann
Writing Good Requirements – A Requirements Working Group Information Report
INCOSE Presentation on Writing Effective Requirements
Build your bottom line: Drive innovation with a collaborative requirements-driven quality solution
A Business Analyst’s soft skills are equally important to succeed in this endeavor. I am sure you must have seen a similar picture that shows how to what extend understanding the requirements of a customer can go wrong. Some of the common mistakes a business analyst make while requirements gathering and analysis are incorrect assumptions, not using the correct level of abstraction, contradicting and inconsistency between requirements and finally over specifying requirements to a spec level. Even using simple language, avoiding generic phrases and using correct grammar becomes handy while writing good requirements.
In our earlier post, we defined requirements as a condition or capability needed by a user to solve a problem or achieve an objective. Often the client provides a high level requirement in the form of a need. These needs, expectations and concepts must be identified, analyzed and elaborated into a set of business requirements. Key requirements in this set should be traced back to the business case provided relating to the need and client's vision.
At a broad level, requirements could be divided into functional and non-functional requirements. Functional requirements provide the high level description of how a system of product should function from the end user's perspective. It provides the essential details of the system for both business and technical stakeholders. Expectations are expressed and managed using functional requirements. Some of the key aspects functional requirements try to address are for whom the product is built, how is it expected to be used, what are the interactions and any guidelines to be followed. Non-functional requirements represent mainly the qualities (expectations and characteristics of the system) and constraints (for example Governmental regulations).
When it compared to requirements levels - we can start with the Requirements Pyramid as shown below(from Requirements Management Using IBM Rational RequisitePro by Peter Zielczynski). It essentially starts from the stakeholder needs at the top to the test cases that verify the implemented requirements at the bottom.
A requirements plan captures all these information. For a template, click here.
This is the second part of our six part blog posts series on basics of requirements management. Read the remaining parts here -