What are requiments?
In the world of business analysis, requimentsdefine 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. Requiments 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, requimentsmay 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 requimentsas 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, requimentscan be about any existing or future system, product, process or procedure.
To write effective requiments, 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 requimentsfor 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 requimentswould 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 requimentsunearth real needs and define effective, clear solutions.
Why are requimentsimportant?
Without defining and adhering to requiments, 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 requiments, the business owner would have built a more expensive solution (a grocery store) than was necessary. Or without effective requiments, 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 requimentshad 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 requimentscosts money and time.
How do you determine what the needed requimentsare?
After you determine the business need, the next step is determining your requiments. This stage is called requimentsdiscovery. Requiments 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 requimentsuntil 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 requiments. 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 requiments?
Normally, business analysts are responsible for eliciting requiments, though other stakeholders may do so as well during various stages of the project's development.
How do you elicit requiments?
You can elicit requimentsvia any reputable method that enables you to glean detailed information related to your project. According to BABOK, requimentselicitation 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 requiments.
What are the basic types of requiments?
Functional requiments are a type of solution requiments. 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 requiments 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 requimentscan 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 requimentsfor your project to function (the delivery trucks would still run without them), obviously a business analyst must not omit any non-functional requimentsif the system is to be successful.
Business requiments state the business needs and tend to be higher-level requiments. 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 requiments 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 requiments.
System requiments 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 requiments 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 requiments?
The goal of requimentsdocumentation is to state each need of the proposed system or process (who, what, where, when and why) precisely and thoroughly. Requiments 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:
Requiments 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 requimentsincluded in this document are examples of written requimentsspecifications.
Diagramming – Requiments 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 requimentsdocuments.
Prototypes – A prototype is a type of interactive preview of what is to be built. If you're writing requimentsfor 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 requimentsprocess?
After you define your elicit, discover, and define your requiments, 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 requiments, the actual development or design process can begin. An analyst must manage each stage of the requimentsprocess with relevant deadlines in mind, and with effective communication to all stakeholder groups.
At many organizations, the requimentsprocess (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 requimentsprocess alone. Software is available to make this process simpler. If you're interested in exploring a system to help you manage your requiments, multiple requimentsmanagement tools are on the market, including a few that are free. One list is available here: http://www.jiludwig.com/Requiments_Management_Tools.html.
For a more information on requimentsand requimentsmanagement and techniques, explore requiments.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.