ITMPI FLAT 002
Main Menu
Home / Project Management / How to Write Good Requirements and Types of Requirements

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: https://www.ibm.com/developerworks/community/blogs/requirementsmanagement/entry/good-requirements-writing?lang=en

About 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.

Check Also

The Power of Questions: Is Your Question an Invitation, Request, or Weapon?

The power of questions—your questions—can either make or break your career. Questions have the power to …

Leave a Reply

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