10 Strategies for Software Requirements Gathering

inShare

No Comments

For many clients, researching the needs and

requirements of a software solution can be a challenge. Meta Group states that 60% 80%
of project failures can be attributed directly to poor requirements gathering, analysis, and
management. With so many stakeholders from executives to end users and people at
headquarters or around the world, critical deadlines can quickly be missed without a
strategy. An even bigger challenge is asking someone to describe their ideal solution
when they may have no idea what lies beyond what they have seen or used to date. Steve
McDonnell, a well published author in the software world, had a great quote on
requirements gathering:

The most difficult part of requirements gathering is not the act of recording what the user
wants, it is the exploratory development activity of helping users figure out what they
want.

Here are a few best practices that can reduce the chances of getting stuck in your tracks or
ending up with incomplete requirements in an evaluation.

1. Choose your interview group wisely.

This can be a challenge for any corporation as too many interviewees and you will have an
extremely long assessment phase, however too few and you can miss vital requirements or
enormous opportunities. Things to consider when picking this group are:

Is there a good cross section of users from all lines of business using the new
solution?
Are regions, offices, or at different levels of tenure in the organization represented?
Do these users have different levels of technical maturity, as your end users will?
How much time do you have to spend on an evaluation?

2. Have a Briefing Packet and Purpose. A large challenge with stakeholder interviews
occurs when the interviewee has only a vague understanding of why they are being
questioned. Creating a summary of the project including why it is beginning, the type of
the questions they will be asked, software jargon and acronyms, along with who will be
affected. This will typically avoid false starts with interviewees asking all the questions or
becoming defensive.
3. Ask Open Ended Questions and Follow Through. When creating a list of the
questions, keep the first tier simple, high level, and extremely open-ended. Although it can
be quite tempting, leading the witness is a major cause for missed opportunities or bad
data. Behind each first tier question, follow up with a set of clarifying questions that dig
into the negative outcomes of the situation, who else is affected indirectly, and optimal
solution requirements.

4. Take a Collaborative Approach. Interviewing one person at a time may not provide
the same creativity or results that collaborative methods can bear. Beginning with a survey
can provide enormous insight into the as is situation and help refine your deeper questions.
Brainstorming sessions or workshops are a great way to take advantage of synergies
between needs and ideas, and are sometimes called Joint Application Development (JAD)
sessions in software development. Another simple technique, which many times are
overlooked, is simply observing an employee perform their job functions.

5. Reverse Engineer Requirements. Existing software packages typically have reporting

mechanisms in place that will give you not only a list of features or existing capabilities,
but also their adoption levels. This provides an understanding of the baseline requirements
you will need in a new system, and which are most popular. There are many reasons why
beneficial features are not used such as bad data, user experience, or lack of training.
Make sure to question users on existing systems and what they find most valuable or lack
in addition to looking at reports.

6. Ask Vendors for a List of Requirements. Vendor requirements, although always

biased to their own product capabilities, can be a good benchmark at this point to
understand how well defined your requirements are, and if there are key gaps in your
overall plan.

7. Create a List of Cutting Edge Requirements. With the rate of change in the software
world, no one at your company may be aware of new capabilities or integrations that can
provide enormous value. Set up a meeting with vendors and ask them about their new
capabilities in the past few releases, along with ones that are coming out in the next
version. This consolidated list of cutting edge requirements may not all be added to your
list, however gives you an understanding of the speed of innovation, how vendors stack up
to their competition in innovation, and whether they are heading in your direction.

8. Poll Users On Requirements and Prioritize. Although you already can assign
requirements a weight of how many times you have heard a particular need, this alone will
not give you a clear picture of importance of needs. After you have compiled
requirements, have users rank these based upon their level of need (no need to critical), and
have a place to get feedback and let them ask questions. Also, its beneficial to flag unique
or complex requirements for cost / benefit analysis based on interviews and further
evaluation.

9. Review Results and Get More Feedback. Sometimes the best feedback can come
from a presentation and report of the findings from the activities to date. Although you
have spoken to everyone prior, a group presentation with data helps reaffirm your
outcomes, allows people to ask questions they may not have had the chance to in the past,
and can bring out some creative ideas people did not think of in the interviews.
10. Use Proof of Concepts (POC)s. Often, when people cannot articulate a need in the
abstract, they can quickly assess if a particular approach would address the need if they can
see it work. Prototypes are most efficiently done with mockups of interfaces and
storyboards, or live technology. This can be helpful as a hand off to the individual vendors
later to replicate in their software.

Have any more creative ways of defining software requirements? Let us know!

Posted in: Requirements, Services, Tools |