In the world of business analysis, requirements define precisely what you are going to create or accomplish—what the effort will include, what it will not include, how it will be done, and by whom. Requirements often also include ancillary (but relevant) information such as possible risks to the project and criteria by which to measure the project's success.
To illustrate this information for the reader, requirements may include not only clearly written text, but charts, graphs, diagrams, use cases, and mock-ups, to name just a few tools in the business analyst's box. BABOK 2.0 defines requirements as including but not being limited to "past, pres¬ent, and future conditions or capabilities in an enterprise, and descriptions of organiza¬tional structures, roles, processes, policies, rules, and information systems." In short, requirements can be about any existing or future system, product, process or procedure.
To write effective requirements, a business analyst must define a project's need as well as the solution. For the purpose of illustration, we will use an example everyone is familiar with (rather than the more common software system). Suppose you were an analyst for a cooperative group of local produce farmers. Your manager came to you and said, "I want you to write requirements for building a local grocery store with heavy emphasis on our farmers' produce." Instead of sitting down specifying what the store should look like, where it should go, and all of its features, you would first explore the need.
You would ask, "Why do you want to build a grocery store?"
Your manager might say, "Our existing produce stands all over town are too few and far between. We need to get produce to customers in an organized, quick way. Most customers don't even know all that of the types of produce that we offer."
Thus you have unearthed the real requirement: An efficient, centralized way to get farmers' produce to customers quickly--not necessarily a store. You ask your manager if an organized, well-advertised produce delivery service would work just as well. Realizing that this would be a significant cost savings over a store and still meet the business need, he agrees.
Your resulting requirements would specify how often the delivery service would run, whether it would run year-round, how customers could participate, effective routes, what to do with produce that is not picked up, etc. Thus requirements unearth real needs and define effective, clear solutions.
Why are requirements important?
Without defining and adhering to requirements, any project will be, at best, incomplete, and at worst, chaos. (And the larger the project, the larger the potential for chaos.)
Also, the newer the project—and the less that is known about it—the bigger the potential for costly mistakes. To use our example above, without requirements, the business owner would have built a more expensive solution (a grocery store) than was necessary. Or without effective requirements, the produce delivery routes would be inefficient, and the farmers' clients might not get their food in time. Or if a delivery truck has maintenance problems and the requirements had not specified a back-up plan, many customers would be unhappy not to get their fresh produce that day, and the cooperative would have to do damage control. A lack of good requirements costs money and time.
How do you determine what the needed requirements are?
After you determine the business need, the next step is determining your requirements. This stage is called requirements discovery. Requirements must be elicited--or drawn out--from stakeholders, existing systems, and available documentation.
A stakeholder is anyone with some level of involvement with the project—they are the people who will build it, grow it, test it, sell it, use it, buy it, market it, and so on. Examples of stakeholders are existing customers, potential customers, business owners, developers, subject matter experts, project managers, engineers, quality analysts, suppliers, and end users. Normally, you cannot know that you have effectively uncovered all of your requirements until you have surveyed a representative from every stakeholder group.
A thorough review of existing systems and documentation related to your project is also useful in eliciting requirements. Before you can improve a system or build a new one, you must have a strong understanding of what is already in place.
Who is responsible for eliciting requirements?
Normally, business analysts are responsible for eliciting requirements, though other stakeholders may do so as well during various stages of the project's development.
How do you elicit requirements?
You can elicit requirements via any reputable method that enables you to glean detailed information related to your project. According to BABOK, requirements elicitation techniques include:
An organization's culture and structure, a project's stakeholders, and a project's complexity and timeline will dictate the best method or combination of methods for eliciting requirements.
What are the basic types of requirements?
Functional requirements are a type of solution requirements. According to BABOK, these "describe the behavior and information that the solution will manage." Continuing with our farming illustration, an example of a functional requirement would be: "This system will deliver produce from farms in our cooperative and deliver it to participating customers."
Non-functional requirements describe needs not essential to the function of the solution, but still essential to the project. They designate the quality and performance of the system being designed, such as speed, accuracy, reliability, and so on. An example related to speed would be "Our delivery system will bring produce from harvest to the customer in less than 48 hours." Non-functional requirements can also include compliance with legal or governmental regulations ("We will adhere to all Department of Agriculture standards for transporting produce"), scalability ("The delivery routing system will be designed in such a way that up to 50 new customers may be added each month,"), redundancy, etc. While you don't need these requirements for your project to function (the delivery trucks would still run without them), obviously a business analyst must not omit any non-functional requirements if the system is to be successful.
Business requirements state the business needs and tend to be higher-level requirements. According to BABOK, they "describe the reasons why a project has been initiated, the objectives that the project will achieve, and the metrics that will be used to measure its success." Since the manager in our farming example noted that most customers didn't know the types of produce that were available in the cooperative, an example of this type of requirement would be: "A list of all available produce grown in our cooperative will be made available to existing and potential customers in print and online on a seasonal basis."
User requirements state needs that relate to the end user (in this case, the buyer). An example would be: "The buyer will be able to track their order and delivery online via an automated tracking system." Use cases are helpful in isolating user requirements.
System requirements state needs that relate to the system performance or maintenance. "All vehicles in the delivery system will be checked for maintenance needs on a weekly basis." A more common real-world system requirement is one related to software usage, such as, "In the event of unscheduled downtime, the system will be able to recover within 10 seconds."
Stakeholder requirements explain the needs of specific stakeholder groups. In our farming example, the cooperative farmers are certainly a stakeholder group, so an example of a stakeholder requirement would be, "Cooperative farmers will have a method to get their produce to customers within 48 hours of harvest."
What are some common methods for documenting requirements?
The goal of requirements documentation is to state each need of the proposed system or process (who, what, where, when and why) precisely and thoroughly. Requirements must also eliminate ambiguity. For example, "The software system will time out when the customer leaves their computer for a while," is a poor requirement. "The system will time out after 60 minutes of inactivity," is better.
Your project will dictate the method that will work best, but a few of the more popular options include:
Requirements specifications – Almost every project includes a written specifications document that includes the features that must be included in your project. They are usually presented in list form, and are often divided into sections. All of the farming cooperative requirements included in this document are examples of written requirements specifications.
Diagramming – Requirements may include a number of different kinds of diagrams, such as sequence diagrams, state diagrams, data flow diagrams, and input/output diagrams, to name a few. Diagramming may be particularly helpful for developers or engineering.
Use cases – Use cases describe the user experience of the end system or product, listing every scenario. You may start with a set of preconditions (i.e., "The user is authenticated into the system and has selected this module"), but you will also include a use case for what happens when the user goes down every conceivable usage path, including alternative scenarios (such as what happens when the user does not select save before navigating away). Use cases may be particularly helpful for quality analysis groups in their testing.
User stories – Commonly used in agile development, user stories are typically short—one to two sentences—and are composed in language the user can understand. For example a sales person who will use the product might write, "I need the system to not only return our delivery timeline data, but also to show what is known about our competitors' delivery times. I need it to come up within seconds so that I can use it in a sales pitch." The purpose of user stories in agile development is to enable quick updates to the project based on user specification without going through the meticulous process of composing and revising formal requirements documents.
Prototypes – A prototype is a type of interactive preview of what is to be built. If you're writing requirements for a software program, a prototype enables stakeholders to see and interact with the current vision of the end product. Almost every stakeholder will benefit from a prototype review, particularly customers and less technical people who have trouble envisioning the end product.
How do I manage the requirements process?
After you define your elicit, discover, and define your requirements, and before the project begins, you must effectively communicate them to necessary stakeholders and get their agreement. Once these stakeholders have signed off on the requirements, the actual development or design process can begin. An analyst must manage each stage of the requirements process with relevant deadlines in mind, and with effective communication to all stakeholder groups.
At many organizations, the requirements process (including review and approval) is managed in conjunction with a project manager. However, in some organizations, an analyst may also manage the project and the entire requirements process alone. Software is available to make this process simpler. If you're interested in exploring a system to help you manage your requirements, multiple requirements management tools are on the market, including a few that are free. One list is available here: http://www.jiludwig.com/Requirements_Management_Tools.html.
For a more information on requirements and requirements management and techniques, explore requirements.com and ModernAnalyst.com.
A Guide to the Business Analyst's Body of Knowledge® (BABOK® Guide), Version 2.0, International Institute of Business Analysis, Toronto, Ontario, Canada, ©2005, 2006, 2008, 2009.
2018-10-18
Requirements.com
All about Requirements
2020-09-20
Requirements.com Staff
What are Requirements?
