Requiremens Overview

What are requiremens?

In the world of business analysis, requiremensdefine 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. Requiremens 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, requiremensmay 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 requiremensas 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, requiremenscan be about any existing or future system, product, process or procedure.

To write effective requiremens, 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 requiremensfor 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 requiremenswould 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 requiremensunearth real needs and define effective, clear solutions.

Why are requiremensimportant?

Without defining and adhering to requiremens, 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 requiremens, the business owner would have built a more expensive solution (a grocery store) than was necessary. Or without effective requiremens, 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 requiremenshad 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 requiremenscosts money and time.

How do you determine what the needed requiremensare?

After you determine the business need, the next step is determining your requiremens. This stage is called requiremensdiscovery. Requiremens 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 requiremensuntil 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 requiremens. 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 requiremens?

Normally, business analysts are responsible for eliciting requiremens, though other stakeholders may do so as well during various stages of the project's development.

How do you elicit requiremens?

You can elicit requiremensvia any reputable method that enables you to glean detailed information related to your project. According to BABOK, requiremenselicitation techniques include:

Brainstorming

Document Analysis (reviewing existing documentation)

Focus Groups

Interface Analysis (reviewing existing interfaces)

Interviews

Observation

Prototyping

Requiremens workshops

Surveys/Questionnaires

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

What are the basic types of requiremens?

Functional requiremens are a type of solution requiremens. 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 requiremens 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 requiremenscan 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 requiremensfor your project to function (the delivery trucks would still run without them), obviously a business analyst must not omit any non-functional requiremensif the system is to be successful.

Business requiremens state the business needs and tend to be higher-level requiremens. 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 requiremens 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 requiremens.

System requiremens 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 requiremens 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 requiremens?

The goal of requiremensdocumentation is to state each need of the proposed system or process (who, what, where, when and why) precisely and thoroughly. Requiremens 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:

Requiremens 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 requiremensincluded in this document are examples of written requiremensspecifications.

Diagramming – Requiremens 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 requiremensdocuments.

Prototypes – A prototype is a type of interactive preview of what is to be built. If you're writing requiremensfor 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 requiremensprocess?

After you define your elicit, discover, and define your requiremens, 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 requiremens, the actual development or design process can begin. An analyst must manage each stage of the requiremensprocess with relevant deadlines in mind, and with effective communication to all stakeholder groups.

At many organizations, the requiremensprocess (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 requiremensprocess alone. Software is available to make this process simpler. If you're interested in exploring a system to help you manage your requiremens, multiple requiremensmanagement tools are on the market, including a few that are free. One list is available here: http://www.jiludwig.com/Requiremens_Management_Tools.html.

For a more information on requiremensand requiremensmanagement and techniques, explore requiremens.com and ModernAnalyst.com.