Loading in 2 Seconds...
Loading in 2 Seconds...
User Requirements Phase Drawn from Sommerville and S. Lauesen , Software Requirements, Styles and Techniques , Addisson Wesley, 2002. Overview. User requirements capture and analysis is an early phase of every lifecycle model.
User Requirements PhaseDrawn from Sommerville and S. Lauesen, Software Requirements, Styles and Techniques, Addisson Wesley, 2002
1: what can we actually take responsibility for?
2: what is the right level of requirement?
Documentation standards: PSS-05, IEEE 830
Non-Functional(AKA Quality) Requirements:
Using a variety of tools and techniques
A good analyst:
1. Invite participants: 6-18 people, all stakeholders represented, max 30% are suppliers
2. Open the meeting: present the topic, let people get to know each other and relax
3. Bad experiences: roundtable discussion of past experiences with similar products or work domains. Record issues on whiteboard. Record ideas on whiteboard. Facilitator makes sure no one dominates. Supplier staff are low key
4. Imagine the Future: Invite ideas, invite speculation. Ask: why/when do you want this? Record ideas.
5. List the issues: edit on the fly, regroup and organise, combine similar. Record issues.
6. Prioritize issues: Each stakeholder group picks top ten – but don’t prioritize within these to avoid conflict.
7. Review the lists: rountable comment, and close the meeting
year is a 2-digit number
99 + 1 = 00 > 99 contradiction!
Simplified model of the Year 2000 Problem
The five (ease of) usability factors (Schneiderman
Some developers claim we cannot optimize all 5,
if so … which to prioritize?
While other requirements support use-cases ...
safety requirements prevent abuse-cases.
Customer has certain assets to be protected
We will examine security under risk
management later …
+ easily understood (esp. by end-user)
+ no technical training needed
+ very high-level/compact requirements
E.g. tables, decision trees, fault trees, data dictionaries
+ understood by end-user (sometimes)
+ small technical training
+ some structure (e.g. nouns, verbs, relations etc)
+ improve completeness issues
e.g. UML, SDL, Petri Nets, etc
+ quite or very precise
+ increasing tool support
+ often standardized / multiple vendors, courses, books, consultants
Logic: e.g. OCL, JML, VDM, Z, B, temporal logic
Ad-hoc: e.g. queuing theory, Markov chain
+ good tool support for validation problems
+ can be used to generate test cases, prove code correctness
+ extremely precise and accurate
rates if a customer asks for a discount.