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

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

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 with stakeholders Developers present their understanding of requirements Stakeholders correct this understanding Discussion and negotiation of disagreed upon requirements Developers revise 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