By now you should know what is a requirement? In the world of business analysis a requirement defines a feature that a future solution, a function that a future solution has to execute like calculate savings or fact that a future solution has to enforce. Requirements are the foundation upon which information systems are built and just like a building if the foundation is not solid the building will not stand.
Fundamentally a requirement is how we communicate what the builders or buyers of the solution need to build or buy, this gets us fully into the world of human communication with all its misunderstandings, misinterpretations and misrepresentations. Finally what requirements are depends to some degree on the software development methodology or SDM that your organization uses and where in the development life cycle you are. In an agile SDM requirements are fundamentally negotiable whereas in a traditional water fall or intuitive SDM changes are only allowed within a rigorous change management process. To reduce the problem of communication between those who want the solution and those who can provide it the International Institute for Business Analysis or IIBA in its business analysis body of knowledge BABOK defines four fundamental types of requirements.
- Business requirements define the goals and objectives that the organization as a whole strives to achieve,
- Stakeholder requirements are the specific needs and wants of groups and individuals within the organization,
- Solution requirements are the functions and qualities that a solution has to encompass to be accepted, transition requirements define attributes and actions necessary to implement the new solution in the existing organization.
- As you can see each type of requirement expresses a different level of detail, business requirements are very high level and a typical project will address very few, business requirements begets stakeholder requirements, begets solution requirements.
- A typical project requires many stakeholder requirements to specify the business requirements from the perspective of the people involved, solution requirements tend to focus on the stakeholder requirements towards the solution technology, there can be a very large solution requirements.
- Finally Transition requirements define components of the solution that only exists to replace the current solution as it exists today.
Let’s look at each type in more detail.
Business requirements define high level goals and objectives of an organization as a whole and address the question why is this project needed? The executive level within the organization usually defines the business requirements, their primary purpose is to prioritize and resource projects. Complete simple sentences potentially with collaborating explanations and cross references, charts and diagrams are the preferred modes for each business requirements. In an agile environment they may be expressed as ethics, features or user stories. The default recommended structure for a good business requirement textual statement follows the mode to achieve a business outcome. The organization or a group within need/ want/wlll/ should do something. For example, to maintain our leadership role within the country BA experts needs to increase gross online sales by 15% this fiscal year or to increase our customer retention the claims department needs to reduce claims processing time from 10 days to 4 days by the end of the third quarter.
Stakeholder requirements express the needs and wants of one or more stakeholders and how they will interact with a solution. Stakeholder requirements bridge business and solution requirements, interviews, joint requirements planning or JRP sessions and user story workshops are common tools for gather stakeholder requirements which should be self authored by the various stakeholders. Ideally, stakeholder requirements limit premature technology decisions meaning they express what is needed not how it will be achieved. Some exceptions apply, for instance if the goal of the project is to migrate functionality to a website the use of terms such as online, via the internet etc are acceptable. Stakeholder requirements can be expressed as simple statements, spreadsheets, user views, models, epics/user stories, business usecases, workflows etc with or without models or diagrams. A commonly used structure for a simple textual stakeholder requirement has evolved into a format known as user story. Although user stories originated in an agile SDM they have proven to be valuable for any SDM. They follow the format As a stakeholder/group, I or we can or cannot do know or have something to achieve my goal or objective. For example, as a customer I can browse the current product catalogue to select items that I want to buy, another example, as a website visitor I can view the cost of coverage for each insurance provider to select the cheapest. Note that this structure assumes that the proposed solution already exists.
Solution requirement describes specific characteristics of a solution that meet business and stakeholder requirements and come in two flavors. Solution functional requirements define what the solution has to do or know. Solution quality requirements work commonly albeit misleading non functional requirements define characteristics that any solution must exhibit for it to be acceptable. The most common sources of solution requirements are the analysis of business and stakeholder requirements, analysis of existing IT systems and associated stakeholder interviews including a particular year the IT group. Common examples for expressing functional solution requirements are lists of functions typically in verb/object form, solution used cases, detailed user stories, lists of data elements, prototypes or mockups of user views, process diagrams, data models, activity diagrams, class models etc. Because the solution requirements are close to the technology the representation should be easy for the developers to use. Typical functional solution requirements include the steps of a process including sequence, decisions, alternatives, exceptions and responsibilities i.e. calculate total charges including delivery cost and taxes. Business rules including calculations, derivation rules, authority levels and event responses i.e. do not ship goods to customers with overdue accounts, business data components including user views, relationships and meta-data, the monthly aging report. The most common form for expressing quality solution requirements are complete simple sentences describing a quality in measurable terms. Typical quality solution requirements address things like legal requirements, service level agreements, contractual obligations, audit requirements, internationalization requirements, corporate standards, reliably, availability, through put maintainability, flexibility, scalability, portability and usability.
Transition requirements describe capabilities needed to integrate the proposed solution into the existing environment, they describe capabilities that the solution must have to facilitate getting from the as is to the to be but will not be needed once the new solution is in production. Initially defined in complete sentences other viable forms for expressing detailed transition requirements are interfaces, database conversions, workflow designs, process models, data models, job descriptions, training programs and job aids. A thorough understanding of the selected solution and of the current environment ultimately dictates the transition requirements. This implies that it is impossible to finalize the transition requirements before the design of the selected solution is complete. Examples of transition requiems are sales personnel must attend the 2-day new customer acquisition program prior to using the new sales support system. All existing customer data will be maintained in both the old and the new database format until the end of the first quarter.
All four levels of requirements create a complete picture of the solution that both the business community and the developer community can understand. As you can see here business requirements leads to stakeholder requirements leads to solution requirements lead to transition requirements.
A level of detail is a question of timing, in an agile SDM details are discussed incrementally as late as possible while in a traditional SDM they’re crafted in the requirements definition document during the analysis phase of the project. Nonetheless, the buying and the understanding of all requirements by the appropriate target audiences at a sufficient level of detail is crucial to implementing any viable solution