Project Management

How to Write Good Requirements and Types of Requirements

Writing requirements are the backbone of everything in IT – all scope, cost estimation, scheduling, coding, testing, and release management start with requirements. Without them, all the time, money, and effort that go into a project are wasted. According to IBM’s Requirements Management Blog’s Vijay Sankar, writing them well ‘requires’ that they be simple, verifiable, necessary, achievable, and traceable.

Sankar defines requirements as “a condition or capability needed by a user to solve a problem or achieve an objective.” How does one obtain user knowledge? Oftentimes a business analyst (BA) interacts directly with clients, references business cases, or responds to a request for proposal (RFP). Many of the skills needed by the BA are soft and require the right attention to detail when interacting with clients.

Functional vs. Nonfunctional

There are two types of requirements, as specified in Sankar’s post:

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.

Non-functional requirements deal with qualities and constraints. For example, government regulations may intervene with user expectations, as well as the inherent limitations of the system in question.

The Requirements Pyramid

Any client need becomes specified as a requirement through identification, analysis, and elaboration, until they resemble a set of business requirements. One helpful tool is the requirements pyramid, which visually represents the hierarchical nature of ‘needs’ as they are disseminated from top to bottom into features, then use cases, then scenarios, and finally into test cases. To be sure, the BA must be specific in their requirements writing without getting into microscopic detail, and needs to steer clear of assumptions and misguided abstractions when interpreting client needs.

Read the original post at:

Eric Anderson

Eric Anderson is a staff writer for CAI's Accelerating IT Success. He is an intern at Computer Aid Inc., pursuing his master's degree in communications at Penn State University.

Related Articles

Leave a Reply

Your email address will not be published. Required fields are marked *

Back to top button

We use cookies on our website

We use cookies to give you the best user experience. Please confirm, if you accept our tracking cookies. You can also decline the tracking, so you can continue to visit our website without any data sent to third party services.