requirements for project management
john cena
ElicitationWrap-up.pptx
1
GCIS 514
Requirements and Project Management
Elicitation Wrap-up
Richard Lamb, MS
Requirements validation
Concerned with demonstrating that the requirements define the system that the customer really wants.
Requirements error costs are high so validation is very important
Fixing a requirements error after delivery may cost up to 100 times the cost of fixing an implementation error.
Requirements checking
Validity. Does the system provide the functions which best support the customer’s needs?
Consistency. Are there any requirements conflicts?
Completeness. Are all functions required by the customer included?
Requirements checking
Realism. Can the requirements be implemented given available budget and technology
Verifiability. Can the requirements be checked?
Traceable.
Elicitation Goals
Requirements Specification
Clear
Concise
Consistent
Correct
Unambiguous
Agreement
Documentation
Analysis
Elicitation
Refer to Chapter 7 page 121 of Software requirements
Also, Chapter 4 page 63 of the BABOK Guide
Comparison of Data-Gathering Techniques1
| Technique | Good for | Kind of data | Plus | Minus |
| Questionnaires | Answering specific questions | Quantitative and qualitative data | Can reach many people with low resource | The design is crucial. Response rate may be low. Responses may not be what you want |
| Interviews | Exploring issues | Some quantitative but mostly qualitative data | Interviewer can guide interviewee. Encourages contact between developers and users | Time consuming. Artificial environment may intimidate interviewee |
7
Comparison of Data-Gathering Techniques1
| Technique | Good for | Kind of data | Plus | Minus |
| Focus groups and workshops | Collecting multiple viewpoints | Some quantitative but mostly qualitative data | Highlights areas of consensus and conflict. Encourages contact between developers and users | Possibility of dominant characters |
| Naturalistic observation | Understanding context of user activity | Qualitative | Observing actual work gives insight that other techniques cannot give | Very time consuming. Huge amounts of data |
| Studying documentation | Learning about procedures, regulations, and standards | Quantitative | No time commitment from users required | Day-to-day work will differ from documented procedures |
8
Analysis of Existing Systems (1)
Useful when building a new improved version of an existing system
Important to know:
What is used, not used, or missing
What works well, what does not work
How the system is used (with frequency and importance) and it was supposed to be used, and how we would like to use it
9
Analysis of Existing Systems (2)
Why analyze an existing system?
Users may become disillusioned with new system or do not like the new system if it is too different or does not do what they want (risk of nostalgia for old system)
To appropriately take into account real usage patterns, human issues, common activities, relative importance of tasks/features
10
Analysis of Existing Systems (2)
Why analyze an existing system?
To catch obvious possible improvements (features that are missing or do not currently work well)
To find out which "legacy" features can/cannot be left out
11
Review Available Documentation
Start with reading available documentation
User documents (manual, guides…)
Development documents
Requirements documents
Internal memos
Change histories
12
Review Available Documentation
Of course, often these are out of date, poorly written, wrong, etc., but it's a good starting point
13
Requirements Elicitation
Domain Subject Matter Expert
Domain Subject Matter Expert: provides supporting materials as well as guidance about which other sources of business analysis information to consult.
May also help to arrange research, experiments, and facilitated elicitation.
14
Questionnaires Have Down-sides
Low response rates
Low density of responses per questionnaire
Lose face-to-face dynamics
Questionnaires Have Down-sides
Signature on form increases credibility,
raises inhibitions
Good ones require ….
Extensive planning
Format considerations
Pilot-testing and revision
Workshops
Gather all key stakeholders together
Short
Focused
Preparation
Good, “safe” environment
Provide warm-up, background, materials
Plan an agenda and process
17
Workshops
Outside facilitator can help
Consensus/team-building skills essential
Personable, well-respected
Can chair a ‘challenging’ meeting
18
Elicitation Obstacles to Overcome: Pathological Syndromes
“Yes, but….” syndrome
“If only…” ..
Conceptualization of potential vs. reality
Of, relating to, or manifesting behavior that is habitual, maladaptive, and compulsive
Def:
Elicitation Obstacles to Overcome: Pathological Syndromes
“Undiscovered ruins syndrome
Perfect information about a system is not possible
Need to stop on phase and at least momentarily move on
Elicitation Obstacles to Overcome: Pathological Syndromes
“The User vs. the Developer syndrome
“Us” / “Them” thinking
Tribe paradigm
EX: Requirements Workshop Agenda
| Time | Agenda | Description |
| 8:00-8:30 | Introduction | Review agenda, facilities, rules |
| 8:30-10:00 | Context | Present project status, result of user interviews |
| 10:00-12:00 | Brainstorming | Seeking features |
| 12:00-1:00 | Lunch | Working lunch to keep momentum |
| 1:00-2:00 | Brainstorming | continues |
| 2:00-3:00 | Feature definition | Write short definitions |
| 3:00-4:00 | Idea reduction; prioritization | Order set of features |
| 4:00-5:00 | Wrap-up | Summarize; assign action items |
