Requirements Validation

CSCI 5801: Software Engineering

Requirements Validation

Properties Requirements Must Have

• Correct: Must be what customer actually wants• Complete: Must cover all customer needs• Unambiguous: Must have one interpretation between

customers and developers• Testable: Must be a way to tell if they are met• Consistent : One requirement cannot conflict with

another• Traceable: Must have been specified by a stakeholder• Realistic: Must be achievable given resources

Consistency

• Common problem when group creates a RSD– Conflicting non-functional requirements

• Total response time < time for each scenario in sequence

– Inherent conflicts between different stakeholders• Requires negotiation to resolve, but must detect problem!

– Conflicts between requirements documentation and requirements specification

– Assumptions about what happened/should happen in other scenarios

• Key: Each developer must review entire RSD

Consistency

• Example:– Login scenario:

• Student provides ID, password

– Add scenario:• Student chooses course, name added to course roster

– Advisement scenario:• Advisor approves courses, courses moved from student

list to course roster

Consistency

• Example:– Login scenario:

• Student provides ID, password

– Add scenario:• Student chooses course, name added to course roster

– Advisement scenario:• Advisor approves courses, courses added to course

roster

Where did this information come from? Are we assuming it comes from Login? Can we look up names from IDs?

So is advisement required or not? If not for all, for who? If required, where are courses stored before course roster?

Traceability

• Each feature must originate with some stakeholder– Should record this information in case need to

clarify/negotiate that requirement later

• Non-required features costly– Developers: Writing code nobody will use– Customers: Paying for/supporting features they did

not ask for– Users: Taking unnecessary steps to perform tasks

Realism

• Impossible requirements– Usually involve 0, 100%, very small numbers in non-

functional requirements• No user errors, 100% reliability, Response < .00001 secs…

• Infeasible requirements– Cannot be accomplished given time/resource

constraints• Detect with scheduling tools• Handle with negotiation

Walkthroughs

• Developers meet to evaluate RSD– Each “represents” scenarios they have contributed

• Ideally, all will have already read the entire document

– For each feature in requirements documentation/ customer interviews:• Is there a set of corresponding scenarios that

would accomplish it? (Completeness)

Walkthroughs

• For each scenario:– Author describes to others, who evaluate it

• Do all developers understand it?• Are there any exceptions that have not been considered?• Does it contradict with any other scenarios (particularly ones

they have developed)?• Can it be accomplished based on information from previous

scenarios (created by others)?• Does it conflict with global non-functional requirements?• Is it testable?• Is it realistic?

Prototyping

Prototyping

• Depict how you think the system should work– What it should do, step by step– How it should appear to user

• Test prototypes with customers or users– Best case: large cross-section of users

• Correct the prototypes and use what you learn to implement the actual system

Prototypes

• Goal: Produce quickly• Simplify as much as possible

– UI prototypes (to show users): • Create on paper • Create with simple tools (Photoshop, PowerPoint, html)

– Functional prototypes (i.e., actually runs):• Focus on one or two key scenarios• Don’t worry about good design• Don’t worry about non-functional requirements (speed,

reliability, etc.)

Throwaway vs. Evolutionary

• Evolutionary prototype:– Build final system based on successful prototype

components – Disadvantage: Bad design decisions made to speed up

prototype production become part of final system

• Throwaway prototype:– Do not use in final system– Disadvantage: Customer may think final system is just

about ready!

User Interface Prototypes

• Set of screens user will see during task• Sketch on paper and/or use simple tools

– Don’t worry about colors, exact positions of elements, etc. (doesn’t need to be beautiful!)

– Does need to show all important UI elements– Does need to be understandable by users

Example Prototype

Example Prototype

Example Prototype

Example Prototype

Prototype Evaluation

• Give user task to accomplish– “Register for a day section of CSCI 5801”

• You play part of computer– Let user tell you what buttons they are pressing,

what they are typing in, etc.

• Goal: The user interface should speak for itself– Do not talk to user – see if they can do it

themselves

Prototype Evaluation

• Encourage user to express concerns– Is a screen confusing?

• “I don’t know which button to press next”

– Would additional information help?• “It would be nice if I could see the name of the course

along with the number”

– Would the user like additional options?• “It would be nice if I could exit from any screen”

• With paper prototypes, can fix on spot!

Prototype Evaluation

• Evaluate based on functional requirements– Are the steps demonstrated for use case correct?– Are they complete?

• Additional ideas for functional prototypes– Record session

• Screen capture tools (i.e. Camtasia) useful

– Evaluate based on usability criteria • Number of mistakes made• Amount of time required

Stakeholder Reviews

• Meet with stakeholders to allow them to evaluate requirements– Only way to insure RSD correct, complete, and

unambiguous

• Key: Expect and encourage criticism– Customers know more about domain than you– They probably have good ideas about how to solve

problems– They are your best resource for “debugging” the

requirements

Stakeholder Reviews

Sit down withstakeholders

Developerspresent their

understandingof requirements

Stakeholderscorrect this

understanding

Discussion andnegotiation of

disagreed uponrequirements

Developersrevise

requirements

Stakeholder Reviews

• Sit down with stakeholders:– Find representative set of stakeholders

• But only if their input would be valuable

– Ideally, include some users of system– Limit size if possible (no more than 6 to 8)

• May turn into mob/be too hard to schedule otherwise• But make sure that in long run, all requirements are

reviewed by all stakeholders

Stakeholder Reviews

• Present your version of requirements– Describe each use case/scenario– What is its role in system? What problem does it

solve?

• Keep presentation understandable– “user story” form instead of formal scenario– Simple use case/sequence diagrams– Simple prototypes of what user screens would

look like throughout process

Stakeholder Reviews

• Get feedback from stakeholders– Expect to be interrupted during presentation– If not, ask them questions:

• Do you understand this scenario?• Is this what you were thinking of?• Are there any cases/situations we haven’t thought of?

– Get them to express their corrections in terms of specific scenarios

• Best way to clarify their thoughts and your understanding

– Be sure to keep a record of what they say

Requirement Negotiation

User may have unreal expectations for system

• Talk through the requirement with the client. Why is it wanted? Is there an alternative that is equivalent?

• Explain the reasoning behind your concern. Explain the technical, organizational, and cost implications

• Be open to suggestions. Is there a gap in your understanding? Perhaps a second opinion might suggest other approaches

Requirement Negotiation

• Focus on prioritization rather than eliminating scenarios– We only have so much time; what should be done

first?– Identify must haves, should haves, could haves, won’t

haves– Avoid “feature creep” – adding requirements outside

scope of original project

Requirement Negotiation

• Look for opportunities to use incremental or iterative development processes– Incremental: Is there a part of this system we can

build really well right now, then add more parts later?

– Iterative: Can we build a low-quality version of the entire system, then improve it later?

Requirement Negotiation

• Stakeholders may have conflicting goals– Students: Register for needed classes– Registrar: Make sure prerequisites met

• Important stakeholders may not be easily identifiable (not main users)– Bursar’s office: Collect tuition as soon as possible– Administration: Allow fast registration so know

which courses to cancel

Requirement Negotiation

• Attempt to negotiate compromise acceptable to all– Complex politics may be involved– May require help from supervisor