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.