© Gerald Kotonya and Ian Sommerville Viewpoint-Oriented Requirements Methods.
User Requirements Phase Drawn from Sommerville (9 th edition) Chapter 4 and S. Lauesen, (various...
-
Upload
nathan-warner -
Category
Documents
-
view
214 -
download
0
Transcript of User Requirements Phase Drawn from Sommerville (9 th edition) Chapter 4 and S. Lauesen, (various...
![Page 1: User Requirements Phase Drawn from Sommerville (9 th edition) Chapter 4 and S. Lauesen, (various sections) Software Requirements, Styles and Techniques,](https://reader030.fdocuments.us/reader030/viewer/2022032723/56649d205503460f949f43a5/html5/thumbnails/1.jpg)
1
User Requirements Phase
Drawn from Sommerville (9th edition) Chapter 4 and S. Lauesen, (various sections) Software Requirements,
Styles and Techniques, Addison Wesley, 2002
![Page 2: User Requirements Phase Drawn from Sommerville (9 th edition) Chapter 4 and S. Lauesen, (various sections) Software Requirements, Styles and Techniques,](https://reader030.fdocuments.us/reader030/viewer/2022032723/56649d205503460f949f43a5/html5/thumbnails/2.jpg)
2
Overview
• User requirements capture and analysis is an early phase of every lifecycle model.
• Capture means finding out what the user wants … using different dialog techniques … and documenting this.
• Analysis means studying the documented requirements for errors and technical consequences
![Page 3: User Requirements Phase Drawn from Sommerville (9 th edition) Chapter 4 and S. Lauesen, (various sections) Software Requirements, Styles and Techniques,](https://reader030.fdocuments.us/reader030/viewer/2022032723/56649d205503460f949f43a5/html5/thumbnails/3.jpg)
3
Definition
(IEEE) A requirement is:
1. A condition or capability needed by a user to solve a problem or achieve an objective
2. A condition or capability that must be met or possessed by a system or component to satisfy a contract, standard, specification, or other formally imposed document
3. A documented representation of 1 or 2.
![Page 4: User Requirements Phase Drawn from Sommerville (9 th edition) Chapter 4 and S. Lauesen, (various sections) Software Requirements, Styles and Techniques,](https://reader030.fdocuments.us/reader030/viewer/2022032723/56649d205503460f949f43a5/html5/thumbnails/4.jpg)
4
Terminology• Product: the system to be delivered• Inner domain: product + surrounding work area, immediate users,
their activities, other systems• Outer domain: customers, “second-level users”, AKA business domain• Product I/O• Domain I/O• Product-level requirements• Domain-level requirements• Actor: human or external system that communicates with the product• Stakeholder: people who ensure the success of the project. (Not the
same as actors, why?)
![Page 5: User Requirements Phase Drawn from Sommerville (9 th edition) Chapter 4 and S. Lauesen, (various sections) Software Requirements, Styles and Techniques,](https://reader030.fdocuments.us/reader030/viewer/2022032723/56649d205503460f949f43a5/html5/thumbnails/5.jpg)
5
Terminology
Product
Platform
Other systems
Product I/O
Domain I/O
Inner Domain=? company
Outer orBusiness Domain=? Business environment
Actors
Stakeholders
![Page 6: User Requirements Phase Drawn from Sommerville (9 th edition) Chapter 4 and S. Lauesen, (various sections) Software Requirements, Styles and Techniques,](https://reader030.fdocuments.us/reader030/viewer/2022032723/56649d205503460f949f43a5/html5/thumbnails/6.jpg)
6
Why do IT projects fail?
• Annual CHAOS report (Standish Group)• Survey of over 10,000 IT projects since 1994– Challenged: >190% of cost estimate– Failed: cancelled or never implemented– Succeeded: on time, to budget
![Page 7: User Requirements Phase Drawn from Sommerville (9 th edition) Chapter 4 and S. Lauesen, (various sections) Software Requirements, Styles and Techniques,](https://reader030.fdocuments.us/reader030/viewer/2022032723/56649d205503460f949f43a5/html5/thumbnails/7.jpg)
7
CHAOS = chaos!
• 31% of projects are challenged• 53% are failed• 16% succeed
EU ESPITI survey (1996) identified 2 major issues1. Poor requirements specification2. Poor requirements management
Let’s look more closely at underlying factors …
![Page 8: User Requirements Phase Drawn from Sommerville (9 th edition) Chapter 4 and S. Lauesen, (various sections) Software Requirements, Styles and Techniques,](https://reader030.fdocuments.us/reader030/viewer/2022032723/56649d205503460f949f43a5/html5/thumbnails/8.jpg)
8
Success and Failure Factors (CHAOS)
• Failure factors– Incomplete requirements– Lack of user involvement– Lack of resources
• Challenged factors– Lack of user input– Incomplete requirements and specifications– Changing requirements and specifications
• Success factors– User involvement– Executive management support– Clear statement of requirements
![Page 9: User Requirements Phase Drawn from Sommerville (9 th edition) Chapter 4 and S. Lauesen, (various sections) Software Requirements, Styles and Techniques,](https://reader030.fdocuments.us/reader030/viewer/2022032723/56649d205503460f949f43a5/html5/thumbnails/9.jpg)
9
Cost Perspective
• Davis 1994, summarised cost studies by IBM, HP etc.
Phase Cost
Requirements Definition 1-2
Design 5
Coding 10
Unit Testing 20
Acceptance Testing 50
Relative cost of changing requirements at different phases in an IT project
![Page 10: User Requirements Phase Drawn from Sommerville (9 th edition) Chapter 4 and S. Lauesen, (various sections) Software Requirements, Styles and Techniques,](https://reader030.fdocuments.us/reader030/viewer/2022032723/56649d205503460f949f43a5/html5/thumbnails/10.jpg)
10
Some Conclusions
1. Avoid requirements capture/analysis/management and we probably crash the project.
2. Requirements need to be debugged as soon as possible.
![Page 11: User Requirements Phase Drawn from Sommerville (9 th edition) Chapter 4 and S. Lauesen, (various sections) Software Requirements, Styles and Techniques,](https://reader030.fdocuments.us/reader030/viewer/2022032723/56649d205503460f949f43a5/html5/thumbnails/11.jpg)
11
Requirements Types according to RUP
• Rational Unified Process (RUP)• A methodology to support UML users• Three types of requirements:
1. Stakeholder requests2. Features3. Use cases
![Page 12: User Requirements Phase Drawn from Sommerville (9 th edition) Chapter 4 and S. Lauesen, (various sections) Software Requirements, Styles and Techniques,](https://reader030.fdocuments.us/reader030/viewer/2022032723/56649d205503460f949f43a5/html5/thumbnails/12.jpg)
12
1. Stakeholders Requests (STRQ)
General requirements which describe the stakeholders needs on a high level. Normally elicited in the beginning of a development cycle by listening to stakeholders needs
![Page 13: User Requirements Phase Drawn from Sommerville (9 th edition) Chapter 4 and S. Lauesen, (various sections) Software Requirements, Styles and Techniques,](https://reader030.fdocuments.us/reader030/viewer/2022032723/56649d205503460f949f43a5/html5/thumbnails/13.jpg)
13
2. Features (FEAT)
High level functionality that the system shall fulfill. Each feature should be derived from stakeholder requests and traceable back to them.
![Page 14: User Requirements Phase Drawn from Sommerville (9 th edition) Chapter 4 and S. Lauesen, (various sections) Software Requirements, Styles and Techniques,](https://reader030.fdocuments.us/reader030/viewer/2022032723/56649d205503460f949f43a5/html5/thumbnails/14.jpg)
14
3. Use Cases (UC)
Express in a detailed way how users interact with the system. Use cases describe how to put and get information into and from the system. A use case should be derived from on or more features. Sufficient detail is needed to support later architectural and detailed design work.
![Page 15: User Requirements Phase Drawn from Sommerville (9 th edition) Chapter 4 and S. Lauesen, (various sections) Software Requirements, Styles and Techniques,](https://reader030.fdocuments.us/reader030/viewer/2022032723/56649d205503460f949f43a5/html5/thumbnails/15.jpg)
15
Example
• STRQ BUYPROD: The system shall offer functionality for buying products.
• FEAT SEARCHNN: The user shall be able to search for a product via article name or number
• UC SEARCHNN: – Step 1: User enters an article name or number– Step 2: User asks system to find product– Step 3: System presents product for user
![Page 16: User Requirements Phase Drawn from Sommerville (9 th edition) Chapter 4 and S. Lauesen, (various sections) Software Requirements, Styles and Techniques,](https://reader030.fdocuments.us/reader030/viewer/2022032723/56649d205503460f949f43a5/html5/thumbnails/16.jpg)
16
Scale of Requirements(responsibility)
Contract tenders shall always be accurate to within 5%
Goal-level requirement(Organisational)
Product shall support cost recording and quotation with historical data
Domain-level requirement
Product shall have recording and retrieval functions for historical data
Product-level requirement
System shall have screen pictures as shown in App. xx
Design-level requirements
Questions: 1: what can we actually take responsibility for?2: what is the right level of requirement?
![Page 17: User Requirements Phase Drawn from Sommerville (9 th edition) Chapter 4 and S. Lauesen, (various sections) Software Requirements, Styles and Techniques,](https://reader030.fdocuments.us/reader030/viewer/2022032723/56649d205503460f949f43a5/html5/thumbnails/17.jpg)
17
Typical URD Structure
1. Introduction: including business goals2. Limits of the system: scope and interfaces3. Data requirements: data model + dictionary4. Product functional requirements: function
lists, feature reqs, process descriptions5. Quality requirements: non-functionalDocumentation standards: PSS-05, IEEE 830
![Page 18: User Requirements Phase Drawn from Sommerville (9 th edition) Chapter 4 and S. Lauesen, (various sections) Software Requirements, Styles and Techniques,](https://reader030.fdocuments.us/reader030/viewer/2022032723/56649d205503460f949f43a5/html5/thumbnails/18.jpg)
18
Types of Requirements
• Functional requirements: describe what the system does, in terms of input data, output date, error messages, etc.
• E.g. a spreadsheet, a database, a word processor, 3D game, etc
![Page 19: User Requirements Phase Drawn from Sommerville (9 th edition) Chapter 4 and S. Lauesen, (various sections) Software Requirements, Styles and Techniques,](https://reader030.fdocuments.us/reader030/viewer/2022032723/56649d205503460f949f43a5/html5/thumbnails/19.jpg)
19
Types of Requirements
Non-Functional (AKA Quality) Requirements:• “everything else”• The product• The development process• The system environment
• We can place these in a taxonomy (Sommerville) or checklist • See also:
– McCall and Matsumoto (1980)– ISO 9126– IEEE 830 (software requirements specifications)
![Page 20: User Requirements Phase Drawn from Sommerville (9 th edition) Chapter 4 and S. Lauesen, (various sections) Software Requirements, Styles and Techniques,](https://reader030.fdocuments.us/reader030/viewer/2022032723/56649d205503460f949f43a5/html5/thumbnails/20.jpg)
20
Non-functional
Product Organizational External
Usability
Efficiency
Reliability Portability
speed
throughput
memory
delivery
implementation
standards
legislative
interoperability
ethical
privacy/security
safety commercial
![Page 21: User Requirements Phase Drawn from Sommerville (9 th edition) Chapter 4 and S. Lauesen, (various sections) Software Requirements, Styles and Techniques,](https://reader030.fdocuments.us/reader030/viewer/2022032723/56649d205503460f949f43a5/html5/thumbnails/21.jpg)
21
Requirements Capture
• An iterative dialog between
• End-usersRequirements
Analysts
using a variety of tools and techniques
![Page 22: User Requirements Phase Drawn from Sommerville (9 th edition) Chapter 4 and S. Lauesen, (various sections) Software Requirements, Styles and Techniques,](https://reader030.fdocuments.us/reader030/viewer/2022032723/56649d205503460f949f43a5/html5/thumbnails/22.jpg)
22
Why don’t we just ask the Customer?
• Stakeholders may have difficulty expressing their needs, or may ask for a solution that doesn’t meet their needs.
• Stakeholders can have conflicting demands• Users find it difficult to imagine new ways of doing things,
or to imagine the consequences of what they ask for• A system that fulfills the requirements may not fulfill user
expectations• Sometimes there are no users because a product is
completely new• Demands and the environment change over time
![Page 23: User Requirements Phase Drawn from Sommerville (9 th edition) Chapter 4 and S. Lauesen, (various sections) Software Requirements, Styles and Techniques,](https://reader030.fdocuments.us/reader030/viewer/2022032723/56649d205503460f949f43a5/html5/thumbnails/23.jpg)
23
Capture Techniques
A good analyst:1. knows many techniques,2. knows when to use them and when not,3. Combines and modifies techniques according
to specific needs.
![Page 24: User Requirements Phase Drawn from Sommerville (9 th edition) Chapter 4 and S. Lauesen, (various sections) Software Requirements, Styles and Techniques,](https://reader030.fdocuments.us/reader030/viewer/2022032723/56649d205503460f949f43a5/html5/thumbnails/24.jpg)
24
Techniques1. Focus groups (structured)2. Stakeholder analysis (small scale, who, what, why, risks, costs, solutions?)3. (Group) interview (recorded, taped, filmed)4. Observation (see also ethnography / immersive studies)5. Task demo (“here’s how I usually …”)6. Document studies (company info)7. Questionnaires (large scale, capture statistics & opinions, open/closed questions)8. Brainstorm (unstructured – anything goes)9. Domain workshops (business process)10. Design workshops (interface ideas)11. Prototyping (product-level reqs., design-level reqs.)12. Pilot experiments (COTS?)13. Similar companies/ Related products14. Ask suppliers (they know their customers)
![Page 25: User Requirements Phase Drawn from Sommerville (9 th edition) Chapter 4 and S. Lauesen, (various sections) Software Requirements, Styles and Techniques,](https://reader030.fdocuments.us/reader030/viewer/2022032723/56649d205503460f949f43a5/html5/thumbnails/25.jpg)
25
Example: Organizing a Focus Group
1. Set the area of focus2. Invite participants: 6-18 people, all
stakeholders represented, max 30% are suppliers3. Open the meeting: present the topic, let people get
to know each other and relax4. 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
![Page 26: User Requirements Phase Drawn from Sommerville (9 th edition) Chapter 4 and S. Lauesen, (various sections) Software Requirements, Styles and Techniques,](https://reader030.fdocuments.us/reader030/viewer/2022032723/56649d205503460f949f43a5/html5/thumbnails/26.jpg)
26
Focus Group (continued)
5. Imagine the Future: Invite ideas, invite speculation. Ask: why/when do you want this? Record ideas.
6. List the issues: edit on the fly, regroup and organize, combine similar. Record issues.
7. Prioritize issues: Each stakeholder group picks top ten – but don’t prioritize within these to avoid conflict.
8. Review the lists: roundtable comment, and close the meeting
![Page 27: User Requirements Phase Drawn from Sommerville (9 th edition) Chapter 4 and S. Lauesen, (various sections) Software Requirements, Styles and Techniques,](https://reader030.fdocuments.us/reader030/viewer/2022032723/56649d205503460f949f43a5/html5/thumbnails/27.jpg)
27
Requirements Analysis and Validation
• “Are we building the right product”?• i.e. will we build the product the customer
truly wants to have? (at least at some point in time!)
• Paradox: only the customer can determine this … but the customer is non-technical!
![Page 28: User Requirements Phase Drawn from Sommerville (9 th edition) Chapter 4 and S. Lauesen, (various sections) Software Requirements, Styles and Techniques,](https://reader030.fdocuments.us/reader030/viewer/2022032723/56649d205503460f949f43a5/html5/thumbnails/28.jpg)
28
Requirements Analysis
• Analysis involves several types of checks and tests that can be carried out:
• Validity• Consistency• Completeness• Realism• Verifiability
![Page 29: User Requirements Phase Drawn from Sommerville (9 th edition) Chapter 4 and S. Lauesen, (various sections) Software Requirements, Styles and Techniques,](https://reader030.fdocuments.us/reader030/viewer/2022032723/56649d205503460f949f43a5/html5/thumbnails/29.jpg)
29
Validity
• Problem: User may have incorrectly defined a functional requirement. All requirements must be checked for functional correctness
• Methods: – Rapid prototype– Paper model– Animation/simulation– Check existing/historic data– Test case generation– URD reviews– System User Manual
![Page 30: User Requirements Phase Drawn from Sommerville (9 th edition) Chapter 4 and S. Lauesen, (various sections) Software Requirements, Styles and Techniques,](https://reader030.fdocuments.us/reader030/viewer/2022032723/56649d205503460f949f43a5/html5/thumbnails/30.jpg)
30
Consistency
• Problem: User may state requirements that contradict each other (Common with many end-users!)
• E.g. year + 1 > yearyear is a 2-digit number99 + 1 = 00 > 99
contradiction!
Simplified model of the “Year 2000 Problem”
![Page 31: User Requirements Phase Drawn from Sommerville (9 th edition) Chapter 4 and S. Lauesen, (various sections) Software Requirements, Styles and Techniques,](https://reader030.fdocuments.us/reader030/viewer/2022032723/56649d205503460f949f43a5/html5/thumbnails/31.jpg)
31
Consistency
• Methods: • If requirements are formal use constraint
solvers and/or CASE tools for automatic check• Manual check, unclear, error prone,
combinatorial explosion!• Note: problem may not be solved by
prototyping
![Page 32: User Requirements Phase Drawn from Sommerville (9 th edition) Chapter 4 and S. Lauesen, (various sections) Software Requirements, Styles and Techniques,](https://reader030.fdocuments.us/reader030/viewer/2022032723/56649d205503460f949f43a5/html5/thumbnails/32.jpg)
32
Completeness
• Problem: user may have forgotten some requirements, leaving holes in the requirements document. These may possibly be solved arbitrarily … but possibly with conflicts (see inconsistency!)
• Methods: – Rapid prototyping– URD reviews– Test case generation– Use cases analysis– Tables– Fault/ decision trees
![Page 33: User Requirements Phase Drawn from Sommerville (9 th edition) Chapter 4 and S. Lauesen, (various sections) Software Requirements, Styles and Techniques,](https://reader030.fdocuments.us/reader030/viewer/2022032723/56649d205503460f949f43a5/html5/thumbnails/33.jpg)
33
Realism (Feasibility)
• Problem: User may express requirements that are not technically feasible (e.g. performance) or violate some non-functional requirement (e.g. legislative)
• Methods: – Prototyping– Mathematical model/simulation
• (e.g Markov chain, queuing theory)
– URD reviews– External advice (e.g. lawyers)
![Page 34: User Requirements Phase Drawn from Sommerville (9 th edition) Chapter 4 and S. Lauesen, (various sections) Software Requirements, Styles and Techniques,](https://reader030.fdocuments.us/reader030/viewer/2022032723/56649d205503460f949f43a5/html5/thumbnails/34.jpg)
34
Verifiability
• Problem: Users may state requirements which can never be checked/verified,
• E.g. “user interface must be user friendly and easy to use”
• Contractual disputes may emerge• Methods:– Test case generation esp. acceptance tests– Usability metrics
![Page 35: User Requirements Phase Drawn from Sommerville (9 th edition) Chapter 4 and S. Lauesen, (various sections) Software Requirements, Styles and Techniques,](https://reader030.fdocuments.us/reader030/viewer/2022032723/56649d205503460f949f43a5/html5/thumbnails/35.jpg)
35
Numerical Quality RequirementsRequirement Comment
1. Product shall detect license plate and take photo in 0.5 seconds
Physical limits AKA hard-real time req.
2. Product shall compute a room occupation forecast within 2 minutes
Too fast? AKA soft-real time req.
3. Product shall compute a room occupation forecast within 4 minutes
Too slow, supplier makes no effort
4. Product shall compute a room occupation forecast within X minutes.
Open target, but how important?
5. Product shall compute a room occupation forecast within X minutes (customer expects 1 minute)
Open target + expectations
6. Forecast shall be measured 10 times by stopwatch during busy period
Customer might user other approach?
7. Forecast shall be measured by some means specified by customer
Open metric
![Page 36: User Requirements Phase Drawn from Sommerville (9 th edition) Chapter 4 and S. Lauesen, (various sections) Software Requirements, Styles and Techniques,](https://reader030.fdocuments.us/reader030/viewer/2022032723/56649d205503460f949f43a5/html5/thumbnails/36.jpg)
36
Usability = fit for use + ease of use
The five (ease of) usability factors (Schneiderman 1998):1. Ease of learning2. Task efficiency3. Ease of remembering4. Subjective satisfaction5. Understandability
Some developers claim we cannot optimize all 5, if so … which to prioritize?
![Page 37: User Requirements Phase Drawn from Sommerville (9 th edition) Chapter 4 and S. Lauesen, (various sections) Software Requirements, Styles and Techniques,](https://reader030.fdocuments.us/reader030/viewer/2022032723/56649d205503460f949f43a5/html5/thumbnails/37.jpg)
37
Usability MetricsMeasure Customer Risk Supplier Risk
Problem Count: At most 1 of 5 novices shall encounter problems during tasks Q and R
low high
Task Time: Novice shall perform tasks Q and R in 15 minutes, experienced user shall complete Q,R,S in 2.
high
Keystroke counts: Recording breakfast shall be possible with 5 keystrokes per guest, no mouse.
medium
Opinion Poll: 80% of users shall find system easy to learn. 60% shall recommend system to other users
medium high
![Page 38: User Requirements Phase Drawn from Sommerville (9 th edition) Chapter 4 and S. Lauesen, (various sections) Software Requirements, Styles and Techniques,](https://reader030.fdocuments.us/reader030/viewer/2022032723/56649d205503460f949f43a5/html5/thumbnails/38.jpg)
38
Score for understanding: Show 5 users 10 common error messages. Ask for explanation of cause. 80% of the answers shall be correct
medium low
Design-Level Requirements: System shall use screen pictures in app. Xx, buttons work as in app. Yy
high
Product level requirements: For all code fields, user shall be able to select value from drop-down list
medium
Guideline adherence: System shall follow style guide Zz. Menus shall have at most 3 levels.
high low
Development process requirements: Three prototype versions shall be made and usability tested during project.
medium
![Page 39: User Requirements Phase Drawn from Sommerville (9 th edition) Chapter 4 and S. Lauesen, (various sections) Software Requirements, Styles and Techniques,](https://reader030.fdocuments.us/reader030/viewer/2022032723/56649d205503460f949f43a5/html5/thumbnails/39.jpg)
39
Security Requirements
While other requirements support use-cases ...safety requirements prevent abuse-cases.
Customer has certain assets to be protected against threats.
We will examine security under risk management later …
![Page 40: User Requirements Phase Drawn from Sommerville (9 th edition) Chapter 4 and S. Lauesen, (various sections) Software Requirements, Styles and Techniques,](https://reader030.fdocuments.us/reader030/viewer/2022032723/56649d205503460f949f43a5/html5/thumbnails/40.jpg)
40
Requirements Capture Languages
• Requirements need to be recorded as precisely as possible,
• Therefore technical requirements languages are useful
• Large variety of these in many styles• We first consider styles: merits and demerits
![Page 41: User Requirements Phase Drawn from Sommerville (9 th edition) Chapter 4 and S. Lauesen, (various sections) Software Requirements, Styles and Techniques,](https://reader030.fdocuments.us/reader030/viewer/2022032723/56649d205503460f949f43a5/html5/thumbnails/41.jpg)
41
Style: Natural Language
+ easily understood (esp. by end-user)+ no technical training needed+ very high-level/compact requirements- unclear/ ambiguous- debugging is difficult- no inherent structure- no tool support for validation (spell checker?)
![Page 42: User Requirements Phase Drawn from Sommerville (9 th edition) Chapter 4 and S. Lauesen, (various sections) Software Requirements, Styles and Techniques,](https://reader030.fdocuments.us/reader030/viewer/2022032723/56649d205503460f949f43a5/html5/thumbnails/42.jpg)
42
Style: Structured Natural Language
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- unclear/ ambiguous- lack of standards- little tool support
![Page 43: User Requirements Phase Drawn from Sommerville (9 th edition) Chapter 4 and S. Lauesen, (various sections) Software Requirements, Styles and Techniques,](https://reader030.fdocuments.us/reader030/viewer/2022032723/56649d205503460f949f43a5/html5/thumbnails/43.jpg)
43
Tables: a structured style
• Advocated by David Parnas• Informal but structured style• Easily understood by end-users• Many formats, e.g. nested tables• Good for completeness and consistency check• Good for business rules
![Page 44: User Requirements Phase Drawn from Sommerville (9 th edition) Chapter 4 and S. Lauesen, (various sections) Software Requirements, Styles and Techniques,](https://reader030.fdocuments.us/reader030/viewer/2022032723/56649d205503460f949f43a5/html5/thumbnails/44.jpg)
44
1. Double room used as single 25%
2. Family with more than one room, discount for additional rooms
10%
3. Discount at immediate check-in
a. Before 6pm and hotel less than 50% occupied, fair weatherb. Before 6pm and hotel less than 50% occupied, bad weather
a. 25%b. 0%
Requirement x. The product shall suggest the following discount rates if a customer asks for a discount.
![Page 45: User Requirements Phase Drawn from Sommerville (9 th edition) Chapter 4 and S. Lauesen, (various sections) Software Requirements, Styles and Techniques,](https://reader030.fdocuments.us/reader030/viewer/2022032723/56649d205503460f949f43a5/html5/thumbnails/45.jpg)
45
Style: Graphical Requirements Language
e.g. UML, SDL, Petri Nets, etc+ high-level/compact+ quite or very precise+ increasing tool support+ often standardized / multiple vendors, courses,
books, consultants- needs technical training- rarely understood by non-IT people and end-
users
![Page 46: User Requirements Phase Drawn from Sommerville (9 th edition) Chapter 4 and S. Lauesen, (various sections) Software Requirements, Styles and Techniques,](https://reader030.fdocuments.us/reader030/viewer/2022032723/56649d205503460f949f43a5/html5/thumbnails/46.jpg)
46
Style: Formal Specification
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- Needs technical training- Poorly understood by end-users- Notation hard to read, overly detailed or low level
![Page 47: User Requirements Phase Drawn from Sommerville (9 th edition) Chapter 4 and S. Lauesen, (various sections) Software Requirements, Styles and Techniques,](https://reader030.fdocuments.us/reader030/viewer/2022032723/56649d205503460f949f43a5/html5/thumbnails/47.jpg)
47
Data Modeling
• Data models describe data inside and outside the product
• Good for experts, maybe difficult for end-users• Early models can survive all the way to coding• Good for completeness/consistency checking
Options1. Class Diagram (OO analysis) 2. Entity-Relationship diagram (Database theory)3. Data dictionary: terms and meanings4. Data expression: format and legal values. Use regular expressions or DTDs.
![Page 48: User Requirements Phase Drawn from Sommerville (9 th edition) Chapter 4 and S. Lauesen, (various sections) Software Requirements, Styles and Techniques,](https://reader030.fdocuments.us/reader030/viewer/2022032723/56649d205503460f949f43a5/html5/thumbnails/48.jpg)
48
Data Dictionary (aka Glossary)
• A simple dictionary that defines nouns (data classes, data objects and actors). Usually alphabetical ordering for ease of use.
• E.g. – Customer account : every user has a customer
account containing name, address, history …– Address : an address has a name or number
(obligatory), a street name (obligatory), an district name (optional) , a country name (obligatory), and a postcode (obligatory).
![Page 49: User Requirements Phase Drawn from Sommerville (9 th edition) Chapter 4 and S. Lauesen, (various sections) Software Requirements, Styles and Techniques,](https://reader030.fdocuments.us/reader030/viewer/2022032723/56649d205503460f949f43a5/html5/thumbnails/49.jpg)
49
Regular Expressions
• Regular expressions such as ab (cd)*(e I f )+
• Can be useful to define data and file formats.• Can define data filters to prevent file corruption• Can write exception handlers for bad data.• There are many “commercial” ways to define such
expressions such as– BNF : Backus-Naur Format– DTD : XML Data Technical Definition– Finite automata