In this course we have covered many techniques for

artifact-driven elicitation and stakeholder-driven elicitation,

in addition to seeing how that ties into the software development life cycle.

Remember that one single technique will not do the job.

All of the techniques should be combined in some way to

gain knowledge of the system that was and the system to be.

Each technique has its own strengths and limitations,

given the environment in which you're working.

For example, in contextual inquiry,

you can use a combination of workplace observation,

open-ended interviews, prototyping, and possibly more.

In software development life cycles like RAD which

stands for Rapid Application Development,

these are helped by adding in JAD.

JAD, again, is Joint Application Development.

For RAD add JAD,

plus group sessions, plus evolutionary prototyping to be successful.

In agile software life cycles,

or ones that are similar to agile,

storyboarding and determining use cases are also quite key.

In all of this elicitation,

your goal is to determine what your customers actually want and need.

While combining these processes,

you are also working to resolve conflicts,

start to determine risks and

try to get a sense of things that can be omitted or modified.

Scope creep is a big danger.

Scope creep is the idea that stuff is being

added into your project that doesn't actually need to be there.

And it can be done by the developers,

or, more likely, your customers.

Scope creep occurs more and more as discussions occur.

People start to get excited.

As they get excited, they'll talk about things that they'd like to see,

but that isn't actually necessary.

Note these for prioritization.

Your stakeholders will talk about solutions that may not be feasible,

given the environment, budget, or technology.

Keep these points in mind for your risk analysis.

If working with developers at the same time,

you can also run in this scope creep.

Developers can say, oh, well,

this will be really cool,

I can add this in five minutes.

We all know how that goes.

Five minutes goes to one month later.

Huh, that didn't actually work.

Or it could also be something that the customer really didn't even want.

So be careful on both sides as you consider your options.

Keep asking yourself what does the customer really need.

Keep track of all the elicited material in an organized way.

Also, note priorities as you go.

Scope creep leads to delays and budget issues in many cases.

And it's one of the reasons that projects completely fail.

Now that we've talked about techniques for determining

the overall requirements as well as some of the lesser requirements,

next steps in our software requirements specification development

include organizing all of these requirements.

First, we need to analyze the requirements for risk and prioritization.

Then, we need to figure out how to write them.

How do we organize them into a software requirement specification to document.

This document would be used by designers, developers,

testers, and can be involved in business negotiation.

Lastly, we need to remember to manage the requirements in terms of motives,

risks, alternatives and always be prepared for change.

Customers always change their minds.

These topics are all covered in the other courses in the specialization,

on secure software requirements and specifications.

Combining Techniques

Requirements Elicitation: Artifact and Stakeholder Analysis

Meet the Instructors