Requirements Gathering Best PracticeTraining Pack

What is a Requirement?What is a GOOD Requirement?

Gathering RequirementsManaging Requirements

Contents

What is a Requirement?

It's difficult to build a solution if you don't know the requirements (in spite of the fact that many teams still try to do it today!).

Requirements- An Introduction

There are a number of types of requirements:

• Business Requirements- what is the business need

• Functional Requirements- how should the system meet the business requirement

• Technical Requirements- how should the system technically meet the functional requirement

This pack focuses on the creation of Business Requirements.

These are detailed descriptions of the information, business activities, business rules and interactions needed to accomplish the business mission. A business requirement addresses what the business problem 8is, what the business needs to accomplish, and/ or what are the business goals, including…

→ Project Initiation: A statement of purpose, objectives and risks of the project. The project scope description and diagram are the first source of Business Requirements.

→ Information Needs: Descriptions of the business information that is used by the Business Area (entities and attributes).

→ Business Processes/ Activities: Descriptions of the work done by the Business area to accomplish their goals and objectives.

→ Business Rules: Constraints or conditions that control when and how an activity is performed, they are operating principles about the business.

Business Requirements

For each business requirement that is to be automated, describe how it should be automated and what the software will ‘look like’ to the end user. For business requirements that will not be automated, document the manual procedure and employee guidelines. Functional requirements describe the view from the user’s perspective of how the system or process will work, including….

→ Design area scope: Description of which business requirements will be automated.→ System Functionality: How the user will interact with the software. These are often

documented with Use Cases. → Data Definitions: What the business data will look like, allowable values, default values, field

lengths etc.→ Quality Attributes: Descriptions that indicate how well the system performs a behaviour or

lets the user take some action. → User classes: Groups of people who will be using the new application software or process

(actors, external agents).→ User Interfaces: Screen layouts, report layouts and procedural descriptions. → Performance Standards: Volume of transactions, number of users, speed of response, etc→ Security Requirements: Levels of access required, password length and type, audits and/ or

logging required.

Functional Requirements

These are detailed descriptions of database definitions, database triggers, stored procedures, business rule engine logic, program logic, application interfaces, and network components to support the business requirements and the functional requirements. A technical requirement that describes specifically how the business problem will be solved, and reflects the view from the technical world. This includes….

→ Hardware Descriptions: Are there specific types or brands of hardware that must be used?→ Software Descriptions: What development tools will be used, and what programming

language? Database design and data conversion requirements. → Design Flows: Diagrams and descriptions that depict how programs and other system

components interface with each other→ Programming Considerations: Creating reusable modules, following standard programming

naming conventions, and using consistent call sequences. → Interface Requirements: Connections between this system and other existing systems.

These include interfaces, and communication mechanisms for hardware and other software systems.

→ Any additional technical constraints and standards

Technical Requirements

The Importance of Requirements

Organizations need to effectively define and manage requirements to help ensure they the end solution meets the customer/ stakeholder needs, while addressing compliance and staying on schedule and within budget.

The impact of a poorly expressed requirement can be devastating; it can have a domino effect that leads to time-consuming rework, inadequate deliveries and budget overruns.

Even worse, a poor requirement can bring a business out of compliance (leaving the business open to huge financial penalties) or even cause injury or death.

If we don’t know what we are trying to create we will never create a solution that is fit for purpose. For most of our projects we are providing a solution or capability for the business- therefore the business requirements must always come from the business stakeholders!

What is a GOOD Requirement?

The Importance of GOOD Requirements

We don’t just need requirements we need good requirements which are clear and specific. Poor requirements can easily be interpreted in many different ways…

What is a GOOD Requirement?

Because requirements are the foundation of any development project, teams need to understand the attributes of a good requirement.

The best requirements are:• Complete (express a whole idea or statement)• Correct (technically and legally possible)• Clear (unambiguous and not confusing)• Verifiable (it can be determined that the system meets the requirement) • Necessary (should support one of the project goals)• Feasible (can be accomplished within cost and schedule)• Prioritized (tracked according to business need levels) • Consistent (not in conflict with other requirements)• Traceable (uniquely identified and tracked)• Modular (can be changed without excessive impact)• Design-independent (do not pose specific solutions on design)

Make sure the requirement describes completely the user task and information required to support the task. Focusing on system functionality instead of what needs to be accomplished may lead to incomplete requirements.

Example:Incomplete Requirement:‘We must be able to change an employee’s profile information’

→ If we don’t specify the individual components of the employee profile, this requirement is not complete.

Complete Requirement:‘We must be able to change the employees last name, first name, middle initial, street address, city, state, zip code, marital status’

Complete Requirements

The requirements should be appropriate to meet the goals of the project and accurately describe the user’s expectations of the functionality.

Example:Incorrect Requirement:‘Employees only change their name when their address or their marital status changes’

→ Someone who was not familiar with the business area may have assumed this requirement. This requirement is incorrect and must be changed.

Correct Requirement:‘Employees may change their name in the payroll system by providing the appropriate legal proof of the change. The change may come with a change in marital status, address or be made alone’

Correct Requirements

Requirements should be written so that all readers will arrive at a single, consistent interpretation. Ambiguous requirements can result in the wrong system being developed and may not be found during testing due to the incorrect interpretation of the requirements. Example:Ambiguous Requirement:‘Employees are not allowed to work for more than 80 hours in one week’

→ ‘Not allowed’ is an ambiguous phrase. Are they physically removed from the work environment or are they not paid for any hours over 80?

Unambiguous Requirement:‘Employee time worked: the time worked is recorded in hours, the smallest increment recorded is .25 of an hour. If an employee reports more than 80 hour sin a 7 day period, a warning is provided to the supervisor and the payment is held for approval.’

Clear (Ambiguous) Requirements

Each requirement should be testable and verifiable. Example:Unverifiable Requirement:‘The system should be easy to use’

→ This requirement is impossible to test since every user will have a different opinion about what is easy to use or not.

Verifiable Requirement:‘A novice user must be able to add a new employee to the payroll system within 10 minutes’

Verifiable Requirements

Requirements must be necessary and clearly support one of the original project goals or objectives. Example:Unnecessary Requirement:‘’We should be able to enter the employee eye colour’

→ This is a great example of a time when the BA needs to ask, ‘Why is this requirement necessary?’

Necessary Requirements

The business analyst must be sure that all requirements are technologically possible for a reasonable cost.

Example:Unfeasible Requirement:‘The system should automatically be updated when the government changes the law’

→ Although this requirement may be technologically feasible, it would involve a complex interface (and likely new government system) with an outside organisation which would be very expensive and difficult to negotiate. Is it a critical requirement?

Feasible Requirements

Each requirement should be prioritised. Most organisations use the MoSCoW method for prioritisation:

→ Must Have- the system must meet this requirement for the end product to be considered a success.

→ Should Have- the system should have this requirement for it to solve the main business problem.

→ Could Have- it would be good to include this requirement to ensure maximum benefit.

→ Would Have- this is a nice to have requirement which the business could do without if necessary.

Prioritised Requirements

→ Ask Questions- you job is to help the business solve a problem. It’s not always what the person says that’s important, sometimes its how they say it that you need to pay attention to.

→ Listen- Listen to what the business is saying. If you are really listening, what they tell you will lead you to what questions you need to ask.

→ Feedback- next, your job is to provide feedback of what you heard to ensure you understood correctly what they were saying. Do this by repeating back to them what you heard them say using paraphrasing or mirroring their words.

→ Agreement- ensure you have agreement from the business of what the requirement really is.

Remember that questions elicit the business reasons for what they want and you need to act as their guide to define clarity around those needs.

Top Tips for Getting Good Requirements

Gathering Requirements?

The "elicitation" step is where the requirements are first gathered from the stakeholder.

Requirement gathering is often a challenging exercise as you need to work with stakeholders who have day jobs and competing demands. Often the business expect you to create the requirements but without the business input you will not create an end product which is fit for the business purposes. Many techniques are available for gathering requirements. Each has value in certain circumstances, and in many cases, you need multiple techniques to gain a complete picture from a diverse set of clients and stakeholders.

Gathering Business Requirements- An Introduction

The most common technique for gathering requirements is to sit down with the stakeholders and ask them what they need.

Remember that your job as a business analyst is to help the business solve a problem they have.

The discussion should be planned out ahead of time based on the type of requirements you're looking for.

There are many good ways to plan the interview, but generally you want to ask open-ended questions to get the interviewee to start talking and then ask probing questions to uncover requirements.

The dynamic of how your business sponsor’s mind works is the key to understanding their needs. Remember that it’s not always what the person says that is important, sometimes its how they say it that you need to pay attention to.

Gathering Techniques: One to One Interviews

Group interviews are similar to the one-on-one interview, except that more than one person is being interviewed -- usually two to four.

These interviews work well when everyone is at the same level or has the same role.

Group interviews require more preparation and more formality to get the information you want from all the participants.

You can uncover a richer set of requirements in a shorter period of time if you can keep the group focused.

The discussion generated by group interviews allows the teams to ‘thrash’ out requirements to ensure that you get good requirements.

Gathering Techniques: Group Interviews

In a facilitated session, you bring a larger group (five or more) together for a common purpose.

In this case, you are trying to gather a set of common requirements from the group in a faster manner than if you were to interview each of them separately.

These are often held as Conferences and Workshops.

Gathering Techniques: Facilitated Sessions

JAD sessions are similar to general facilitated sessions.

However, the group typically stays in the session until the session objectives are completed.

For a requirements JAD session, the participants stay in session until a complete set of requirements is documented and agreed to

Gathering Techniques: Joint Application Development (JAD)

Questionnaires are much more informal, and they are good tools to gather requirements from stakeholders in remote locations or those who will have only minor input into the overall requirements.

Questionnaires can also be used when you have to gather input from dozens, hundreds, or thousands of people.

Be careful about how you structure and word your questionnaires. Ensure that you do not ask leading questions and ensure that you use open questions as far as possible.

When consolidating data ensure that you accurately represent individuals responses within any outcome statistics.

Gathering Techniques: Questionnaires

Prototyping is a relatively modern technique for gathering requirements.

In this approach, you gather preliminary requirements that you use to build an initial version of the solution -- a prototype.

You show this to the stakeholder, who then gives you additional requirements. You change the application and cycle around with the stakeholder again.

This repetitive process continues until the product meets the critical mass of business needs or for an agreed number of iterations.

A downside of this method is that you can end up forever changing the prototype and never progressing to a full system. To minimize this impact you should set clear timeline for prototyping and set clear expectations on the number of rounds you will conduct.

Gathering Techniques: Prototyping

Use cases are basically stories that describe how discrete processes work.

The stories include people (actors) and describe how the solution works from a user perspective.

Use cases may be easier for the users to articulate, although the use cases may need to be distilled later into the more specific detailed requirements

Gathering Techniques: Use Cases

This technique is especially helpful when gathering information on current processes.

You may find, for instance, that some people have their work routine down to such a habit that they have a hard time explaining what they do or why.

You may need to watch them perform their job before you can understand the entire picture.

In some cases, you might also want to participate in the actual work process to get a hands-on feel for how the business function works today

Gathering Techniques: Following People Around

On some projects, the requirements are not "uncovered" as much as they are "discovered."

In other words, the solution is brand new and needs to be created as a set of ideas that people can agree to.

In this type of project, simple brainstorming may be the starting point.

The appropriate subject matter experts get into a room and start creatively brainstorming what the solution might look like.

After all the ideas are generated, the participants prioritize the ones they think are the best for this solution.

he resulting consensus of best ideas is used for the initial requirements

Gathering Techniques: Brainstorming

Managing Requirements?

Once you have gathered your requirements there are ten steps that can help you better define and manage requirements:

1. Structure Requirements2. Manage and link customer needs, requirements and contracts3. Manage constraints4. Visualize requirements5. Test requirements6. Bridge the chasm between business and development7. Control change to requirements8. Capture and track metrics and trends9. Provide examples of goof requirements10. Reuse Requirements

Managing Requirements: Introduction

Duplicate requirements can cause work to be performed twice, lead to conflicts, and eventually double your maintenance cost.

Omitted requirements may lead to missing functionality or cause shortcomings (see below, “Constraints”).

Requirements should be structured to enhance understanding while avoiding duplication and omission.

Traceability to higher- and lower-level requirements enables teams to assess coverage.

Structuring requirements is the first step in taking control and improving the quality of requirements.

Structure Requirements

Organizations typically collect the stakeholder’s needs, captured “as is.”

These needs undergo an internal translation to requirements in a format that meets the requirements characteristics described above. They may also be made more generic and less customer-specific (so the system can meet multiple customer needs). There is also often a stable contractual agreement, a legally binding third document. Organizations need to capture these levels of user requirements, maintaining intelligent traceability and change impact analysis between them.

Specifications and contractual documents should be generated from the requirements repository; this central location should also maintain links to outside elements (e.g., customer documents, e-mails and contracts).

By managing the multiple representations of customer needs, organizations have better control over contractual agreements and increase the chance of project success.

Manage and link stakeholder needs, requirements and contracts

Requirements must not only describe functional behavior.

Nonfunctional requirements, also called constraints, can be critical for compliance and regulations and can add quality to the system. Typical nonfunctional requirements can specify:→ Performance→ Interface→ Security→ Safety→ Reliability→ Availability→ Maintainability

Writing better requirements includes providing coverage for constraints since shortcomings in these areas (e.g., performance, reliability and ease of use) generally cannot be reengineered back into the system once developed. By ensuring that they take into account all types of constraints relevant to their industry, organizations greatly increase their projects’ chances of success

Manage Constraints

Most requirements analysts find augmenting textual requirements with modeling helpful, whether this means drawing pictures on a whiteboard, utilizing presentation tools such as PowerPoint or simply creating a mental model.

These representations should be managed alongside the requirements to help ensure consistency, traceability and change control.

Visual requirements modeling provides a simple and powerful way to communicate with, and elicit requirements from, customers and end users.

It also helps clarify requirements and create a common understanding between all development team members and stakeholders.

Although models and images should not replace clear, unambiguous textual requirements, by empowering visual requirements, organizations increase communication and collaboration across all stakeholders.

Visualise Requirements

An efficient way to better manage requirements is to ensure they are clearly mapped to test cases.

Making sure each requirement is clearly verifiable from the start not only helps prepare later phases of the project, but it also puts the writer in the correct state of mind.

Note that this is true for the nominal functional mode (making sure the system or software does what it’s supposed to do). Requirements and their associated tests must also indicate what the system should not do, and what happens at the limits (degraded mode).

This rule also applies to constraints (nonfunctional requirements): Indicating how they shall be tested is a good way to write better requirements. For instance, how would we test the requirement “The software must be highly usable”? A better requirement would be, “An untrained user will be able to generate a report in less than three minutes,” for instance.

Organizations that ensure their requirements are clearly testable, early on in the process, can improve project success rates and enhance quality.

Test Requirements

In many cases, the route to better requirements management is to have fewer requirements.

Projects cannot always offer the luxury of implementing all customer requests, marketing ideas and business suggestions when they also have to meet budget and deadline objectives. Rather than trying to manage every requirement, project and product managers must be able to make decisions on those requirements that bring the most value to the customer and help the business improve innovation.

This can be achieved by combining value and priority information from stakeholders and defining the right combination of requirements.

By creating and maintaining this link between engineering requirements and business and customer needs, senior management can help ensure that resources are spent efficiently.

Development and implementation can similarly align technical decisions with the organization’s strategy.

Bridge the Chasm between Business and Development

Requirements are subject to continual change.

As a project progresses, organizations need to remain agile, adapt to engineering imperatives and respond to evolving marketplace situations and customer needs.

Writing a perfect first requirement is insufficient if its evolution isn’t well managed—poorly controlled change can lead to inadequate systems and software, rework effort and loss of revenue.

Organizations need to implement a reliable and repeatable change control process that helps turn this challenge into an opportunity.

As a result, they’ll be more competitive, control schedules and respond to evolving customer needs.

Control Change to Requirements

Today’s complex projects demand automated data collection and reporting facilities to streamline project management. As such, project managers and all stakeholders need a “management dashboard” of metrics and trends that enables them to quickly monitor project activities such as the progress, growth and volatility of actual requirements.

In other words, project managers need to keep their focus on decision making instead of manually gathering data and compiling reports. Most importantly, the display of key requirements monitoring information must be at a high level, allowing users to manage by exception and spot trouble areas quickly.

A high change frequency on a specific requirement or a whole subsystem may indicate that the requirement needs to be revisited with the customer. A large amount of rework on implementation may point at a poorly specified original requirement.

Trends should also be used to learn lessons from past systems and software projects: Could issues and problems have been identified earlier on? This wealth of information must be used to build the organization’s knowledge database.

Capture and Track Metrics and Trends

By providing examples and counterexamples of good requirements and documents, organizations can enhance the quality, consistency and completeness of their requirements.

The next step should be to use good (and bad) requirements from each project that reflect the organization’s domain expertise to build a corporate knowledge database. Textbook requirement examples rarely reflect a company’s needs as well as their own previous experience.

Past requirements should be annotated during a project postmortem to indicate any notable information (positive or negative).

New projects can, for example, examine the traceability that previous projects have used for regulations to understand how they were taken into account, and to identify teams that have already achieved compliance for their projects.

Provide Examples of Good Requirements

When a good requirement has been written for a previous project and it is applicable to a present situation, the natural reaction is to reuse it, generally by copying and pasting the description.

This unfortunately breaks the traceability and eliminates impact analysis. A smarter approach to reuse is to maintain a link between the two requirements (for example, creating a reuse type link).

This enables analysts to access the original requirement at any time to check allocation of implementation, for instance.

Likewise, any changes made to the original requirement (issues detected, updates needed) can lead to the notification of reusing teams.

By implementing smart requirements reuse, organizations can improve knowledge sharing across teams and facilitate impact analysis.

Reuse Requirements

Any Questions?