IS550: Software requirements engineering

1
IS550 Software requirements engineering

• 3. Functional requirements styles

• Dr. Azeddine Chikh

2
Text
Soren Lauesen, "Software Requirements Styles
Techniques"Addison-Wesley Professional 2002,
 608 pp, ISBN-10 0201745704 - ISBN-13
9780201745702                  
3
0. Introduction

• Data requirements specify the data to be stored
  in the system.
• In contrast, functional requirements specify what
  data is to be used for, how it is recorded,
  computed transformed, updated, transmitted, etc.
• The user interface is in most systems as an
  important part of the functions because many data
  are recorded, updated and shown through it.

4
1. Human / computer who does what ?

• Domain model humans and computers united
• Physical model what each of them do
• Product requirements divide the work
• A pervading issue is how the works divided
  between human and computer
• The division is not given in advance, but is
  decided more or less through the requirements

5
1. Human / computer who does what ?

• What should we specify as functional requirements
  to the product ? The functions the product should
  have, for example, the screens we want ? If we do
  this, then we have chosen the division of labor.
• That is a huge responsibility to the requirements
  engineer
• We should either do it very carefully at
  requirements time, or we should avoid specifying
  product functions until design time

6
1. Human / computer who does what ?
Domain model parties joined
guests wishes
FindFree Room
guest name chosen room
Rooms
7
2. Context diagrams (CD)

• What is this ?
• A diagram of the product and its surroundings
• It shows the scope of the product
• It is important but often overloaded
• Advantages of CDs
• Verification. The CD gives developers an
  over-view of the interfaces and serves as a high
  level checklist over what to develop.
• Validation. Most customers can readily understand
  the CD, spot missing interfaces and discuss what
  is to be delivered and what is outside the
  product

8
2. Context diagrams
Hotel system
Account system
R1 The product shall have the following
interfaces
booking, checkout, service note, . . .
confirmation, invoice
Recep- tionist
Telephone system
Guest
9
3. Event list function list (ELFL)

• What is this ?
• Events to be handled by the product (or a list of
  product functions).
• Events to be handled by human computer (or a
  list of user tasks).
• Product events are design-level issues
• An event is something that requests a system to
  perform some function.
• Usually an event arrives with some data telling
  the system what to do.
• An event list shows the types of events that can
  arrive at the system. Since an event causes the
  system to perform a function, we can make a
  similar list of the functions that the system can
  perform

10
3. Event list function list (ELFL)

• Domain events
• Domain events arrive to the domain from the
  surroundings. Sometimes domain events are called
  business events or triggers.
• Domain-level requirements. The requirements are
  that the product shall support the various
  domain events or tasks. It is left to the
  developer to design the necessary product events
  and product functions.
• Product events
• Product events arrive at the product from the
  domain.
• Product -level requirements. The requirements are
  that the product shall handle the various events
  or provide the various functions.

11
3. Event list function list (ELFL)

• User-interface versus technical interface
• For human-computer interfaces, the list of
  functions is reasonable as a product-level
  requirement, while a detailed list of product
  events is a design-level requirement.
• For technical interfaces to other products, the
  detailed list of product events may be highly
  important. The reason is that in this case, the
  product events are determined by an existing
  system, whereas for the user interface, they have
  to be determined during system design.

12
3. Event list function list (ELFL)
Product events
Domain events (business events)
R2 The product shall handle the following events
/ The product shall provide the following
functions User interface R2.1 Find free
room R2.2 Record guest R2.3 Find
guest R2.4 Record booking R2.5 Print
confirmation R2.6 Record checkin R2.7 Checkout R2.
8 Record service Accounting interface R2.9 Period
ic transfer of account data . . .
R1 The product shall support the following
business events / user activities /
tasks R1.1 Guest books R1.2 Guest checks
in R1.3 Guest checks out R1.4 Change
room R1.5 Service note arrives . . .
13
3. Event list function list (ELFL)

• Advantages of ELFL
• Verification. Developers ca easily check that
  each event/function on the list is supported or
  implemented
• Validation. Customers can to some extent validate
  the domain-level lists of events and tasks.
  However, they may find it difficult to check
  whether all events are included. One of the
  problems is that there are many variants of each
  event or activity.
• Analysts can make a consistency check to see that
  the lists are logically complete. They compare
  the lists against the data model Is there an
  event / function that can Create, Read, Update,
  and Delete each entity in the data model ? If
  not, some event or function is probably missing.
  The check can made on the domain level as well as
  the product level

14
3. Event list function list (ELFL)

• Disadvantages of ELFL
• The event list for the user interface is a design
  issue. Make it only if you need design-level
  requirements. If you want a commercial product,
  the list will be useless since the product has
  defined its own events already.
• Customers cannot usually validate the list of
  product events and functions. Unfortunately, they
  are often asked to do so. Customers can better
  validate the list of domain events and tasks.
  

15
4. Feature requirements (FR)

• What is this ?
• Text form the product shall record
  /show/compute
• Many people believe that this is the only
  acceptable type of requirement
• Can lead to a false sense of security for user
  and analyst.
• It is difficult to ensure that users are
  adequately supported and business goals covered

16
4. Feature requirements
R1 The product shall be able to record that a
room is occupied for repair in a specified
period. R2 The product shall be able to show and
print a suggestion for staffing during the next
two weeks based on historical room occupation.
The supplier shall specify the calculation
details. R3 The product shall be able to run in
a mode where rooms are not booked by room number,
but only by room type. Actual room allocation is
not done until checkin. R4 The product shall be
able to print out a sheet with room allocation
for each room booked under one stay.
In order to handle group tours with several
guests, it is convenient to prepare for arrival
by printing out a sheet per guest for the guest
to fill in.
17
4. Feature requirements

• Advantages of FRs
• Validation. Customers love features. They use the
  customers language.
• Verification. It is straightforward to check that
  all the features are implemented in the final
  product.

18
4. Feature requirements

• Disadvantages of FRs
• It is a problem that features are easy to
  formulate, because customers may dream up so many
  features that the whole system becomes
  unrealistic.
• If the customer expects to select a COTS-based
  system, for instance during a tender process, he
  may be tempted to write down the features of one
  particular system that he knows. This will favor
  the supplier of this particular system although
  other suppliers might have better solutions to
  his real problems
• Validation. Although the customer readily
  understands the features, he has great
  difficulties in checking that the features allow
  him to reach his business goals.

19
5. Screens and prototypes

• What is this ?
• Screens pictures and what the buttons do
• Excellent as design-level requirements if
  carefully tested
• Not suited for COTS-based systems

20
5. Screens and prototypes
R1 The product shall use the screen pictures
shown in App. xx. R2 The menu points and
buttons shall work according to the process
description in App. yy. Error messages shall
have texts as in . . . R3 Novice users
shall be able to perform task tt on their own in
mm minutes.
Certificate The requirements engineer has
usability tested this design according to the
procedures in App. zz.
Makes sense?
21
5. Screens and prototypes
Appendix xx. Required screens
Appendix yy. Required functions Stay window Book
. . . Checkin If stay is booked, record the
booked rooms as occupied. If stay is not
recorded, Check selected rooms free and guest
information complete. Record guest and stay.
Record selected rooms as occupied. If stay is
checked in, . . .
22
5. Screens and prototypes

• Advantages of screens as requirements
• Validation the customer can ensure that the
  screens are able to support the tasks and provide
  high usability. However, it is not enough to
  review the screens. Task analysis and usability
  tests have to be made.
• Verification it is straightforward to verify
  that the final user interface is as specified.
  Experience shows, however, that it is a good idea
  to repeat the usability test with the final
  product. Some problems may have crept in during
  development, for instance that the creative
  screen designer introduced flashing fields or
  fancy colors that make the screens less useful
  than in the prototype, or that the system
  response time is inadequate.

23
5. Screens and prototypes

• Disadvantages of screens as requirements
• Dont use this requirements style when the
  product under consideration is a commercial
  product with or without modifications.
• If the tasks are not well defined or the scope of
  the entire product is dubious, it is much too
  early to design screens and use them as
  requirements. However, prototypes may be very
  useful to help illustrate the various
  possibilities.
• If screen design is not suitable for one reason
  or another, we recommend that task descriptions
  to be used as requirements

24
6. Task descriptions

• What is this ?
• Structured text describing user tasks
• Easy to understand for user as well as developer
• Easy to specify variants and complexity
• Simple to verify
• Domain-level requirements also suited to COTS
• A task is what user and product do together to
  achieve some goal
• A use case is mostly the products part of the
  task
• A human task is the users part of the task

25
6. Task descriptions
Task 1.1 Booking Purpose Reserve room for a
guest.
Work area 1. Reception Service guests - small
and large issues. Normally standing. Frequent
interrupts. Often alone, e.g. during
night. Users Reception experience, IT
novice. R1 The product shall support tasks 1.1
to 1.5
Task 1.2 Checkin Purpose Give guest a room.
Mark it as occupied. Start account. Trigger/ Pre
condition A guest arrives Frequency Average 0.5
checkins/room/day Critical Group tour with 50
guests. Sub-tasks 1. Find room 2. Record guest
as checked in 3. Deliver key Variants 1a. Guest
has booked in advance 1b. No suitable
room 2a. Guest recorded at booking 2b. Regular
customer
Missing sub-task?
Task 1.3 Checkout Purpose Release room,
invoice guest. . . .
26
6. Task descriptions
Task Look at your new e-mails Purpose Reply,
file, forward, delete, handle later. Trigger
A mail arrives. - Someone asks you to
look. - You have been in a meeting and are
curious about new mail. Frequency . . .
Triggers, options, preconditions
27
6. Task descriptions

• Advantages of task descriptions
• Validation is easier
• Trace to development
• Verification is straightforward
• Intuitive understanding of the domain level
• Suitable for COTS
• Task specifications can specify complexity and
  many variants in little space
• Disadvantages of task descriptions
• No data specified
• Non-task activities
• Design is harder

28
7. Features from task descriptions

• What is it ?
• Product features explained by means of task
  descriptions
• Improves understanding and validation of the
  features
• You can rarely guess user tasks from the features

29
7. Features from task descriptions
Work area 1. Reception The product is normally
operated standing, and there are many
interruptions. R1.1 Product shall allow
mouse-free operation. R1.2 Product shall support
switching between incomplete tasks. The product
must support checkin, i.e. the guest must get a
room and a key, and accounting must
start. R1.3 Product shall find free rooms of
various types. R1.4 Product shall record checkin
and rooms occupied by that stay. R1.5 Product
shall collect pay information for the
stay. R1.6 Product shall provide electronic
keys. It may take too long time to check in a bus
of pre-booked guests if they are checked in one
by one. R1.7 Product shall print registration
forms in advance for group stays.
30
8. Tasks Support

• What is it ?
• Structured text describing tasks, domain
  problems, and possible support for them
• Identifies critical issues
• Discusses product features in a structured way
• Easy to understand for user as well as developer
  
• Easy specification of variants and complexity
• Simple to verify
• Domain-level requirements also suited to COTS

31
8. Tasks Support
Task 1.2 Checkin Purpose Give guest a room.
Mark it . . . Trigger A guest arrives Frequency
. . .
Sub-tasks 1. Find room. Problem Guest wants
neighbor rooms price bargain. 2. Record guest as
checked in. 3. Deliver key. Problem Guest
forgets to return the key guest wants two
keys. Variants 1a. Guest has booked in
advance. Problem Guest identification fuzzy.
Past Problems
Domain level
32
8. Tasks Support

• Advantages
• Easy to understand what customer wants
• Possible to specify advantages of our solution
• Convincing demonstration at contract time
• Equal opportunities
• Adjust ambitions
• Tracing possible reqs ? business goals
• Disadvantages
• Data-weak Yes, use data descriptions too
• Non-task activities Yes, how?
• Quality reqs Partly related
• Unusual reply format Yes
• More work for developer? Yes User interface
  design!
• More work for customer?

33
9. Scenarios

• What is it ?
• A case story illustrating one or more user tasks,
  or a specific case to be tested
• Improves developer intuition
• Attractive but not requirements
• In UML A scenario (case scenario) is an
  instantiation of a use case

34
9. Scenarios
Scenario The evening duty Doug Larsson had
studied all afternoon and was a bit exhausted
when arriving 6 pm to start his turn in the
reception. The first task was to prepare the
arrival of the bus of tourists expected 7 pm. He
printed out all the checkin sheets and put them
on the desk with the appropriate room key on each
sheet. In the middle of that a family arrived
asking for rooms. They tried to bargain and Doug
always felt uneasy about that. Should he give
them a discount? Fortunately Jane came out from
the back office and told them with her persuading
smile that she could offer 10 discount on the
childrens room. They accepted, and Doug was left
to assign them their rooms. They wanted an
adjoining room for the kids, and as usual he
couldnt remember which rooms were
neighbors. Around 10 pm, everything was quiet,
and he tried to do some of his homework, but
immediately became sleepy. Too bad - he wasnt
allowed to sleep at work until 1 AM. Fortunately
the office computer allowed him to surf the net.
That kept him awake and even helped him with some
of his homework.
Vivid scenario
35
10. Good tasks

• Highlights
• Closed task meaningful user goal
• Check that you have identified all tasks
• Bundle small, related tasks
• Dont program the user dialog

36
10. Good tasks
Good tasks Closed goal reached, pleasant
feeling Session Small, related tasks in one
description Dont program

• Examples
• 1 Manage rooms?
• 2 Book a guest?
• 3 Enter guest name?
• Check in a bus of tourists
• Change the guests address etc?
• 6 Change booking?
• 7 Cancel entire booking?

Frequent mistake

• Got them all?
• All events covered?
• Critical tasks covered?
• At least as good as before?
• CRUD check

How to deal with that?
37
11. High level tasks

• What is it ?
• Total business cases as seen by the clients
• Independent of existing user tasks
• Idea generating business process re-engineering
  (BPR)
• Rarely used as requirements

38
11. High level tasks
Task 1. A stay at the hotel Actor The
guest Purpose . . .
Sub-tasks 1. Select a hotel. Problem We arent
visible enough. 2. Booking. Problem Language and
time zones. Guest wants two neighbor
rooms 3. Check in. Problem Guests want two
keys 4. Receive service 5. Check out Problem
Long queue in the morning 6. Reimburse
expenses Problem Private services on the bill
Example solution ? Web-booking. Choose rooms
on web at a fee. Electronic keys. Use
electronic key for self- checkout. Split into two
invoices, e.g. through room TV.
39
12. Use cases

• Highlights
• Widely used styles
• Some styles are good for designing user dialogs
• Most ignore the users part of the tasks
• Not suitable as requirements for COTS-based
  projects
• A use case is a sequence of related messages
  exchanged among the system and outside actors,
  together with actions performed by the system

40
12. Use cases
UML use case diagram
Hotel system
Booking
actor
Checkin
Receptionist
Checkout
Account system
Transfer
actor
Use cases vs. tasks
41
12. Use cases
Human and computer separated Use case Check in
a booked guest User action System action Enter
booking number Show guest and booking
details Edit details (optional) Store
modifications Push checkin Allocate free
room(s) Display room number(s) Give guest key(s)
Human and/or computer
42
12. Use cases
Computer-centric use case Use case Check in a
booked guest Trigger Receptionist selects check
in Read booking number Display guest and
booking details Read and store
modifications Wait for checkin command Select
free room(s) Mark them as occupied Add them to
guest details Display room number(s) End use case
Human and/or computer
43
12. Use cases
Select checkin
Read booking number
Retrieve booking
Display error message
not found
Activity diagram for first part of checkin
found
Display guest and booking details
Read and store modifications
Detailed product activities
44
12. Use cases

• Advantages of use cases
• The UML use case diagrams may be used as
  top-level checklists for what to specify further
  and what to develop.This may support validation
  as well as verification. Experts agree, however,
  that the diagrams should be supplemented with
  text-based versions.
• Essential use cases have proven useful for
  designing the user interface.
• Disadvantages of use cases
• They say little about the data used in the tasks,
  and they cope poorly with non-task activities.

45
13. Tasks with data

• What is it ?
• Structured text describing user tasks and data
  need for each sub-task
• Useful for screen design and tracing to
  development
• Difficult to validate
• A common problem with all the previous use cases
  styles is that they dont say much about the data
  needed to carry out the various sub-tasks.

46
13. Tasks with data
Task 1.2 Checkin Purpose Give guest a room.
Mark it as occupied. Start account. Trigger Guest
arrives Frequency Average 0.5
checkins/room/day Critical Group tour with 50
guests. Sub-tasks Visible data Virt.
windows 1. Find room Free rooms of kind x,
price Rooms. Crit kind, dates 1a. No suitable
room All free rooms, Rooms. Crit dates price,
discount 1b. Guest booked Guest and stay
details Stay. Crit name ... 2. Record guest
Guest detail, chosen room Stay, Rooms as
checked in 2a. Guest recorded Guest and stay
details Stay at booking 2b. Regular customer Gu
est detail, chosen room Rooms, Stay. Crit name
... 3. Deliver key Room numbers Stay
47
13. Tasks with data

• Validation. Users can validate the data needs,
  but not reliably because the approach is
  abstract.
• Trace to development. Tasks with data are
  excellent for deriving virtual windows or the
  final screens.
• Verification. Checking is straightforward

48
14. Dataflow diagrams

• What is it ?
• A bubble diagram showing functions, and data
  flowing between the functions
• Compact specification of the needed data
• Good as an intermediate work product
• Useful as requirements for workflow applications
• With dataflow diagrams, you can describe tasks in
  a technology-independent way what human and
  computer do together (the domain model). Or you
  can describe what the computer should do (the
  physical model).

49
14. Dataflow diagrams
R1 The product shall support these activities?
Booking request
Booking
guest data
Data expression Booking request guest data
period room type guest data guest name
address pay method
Guests
periodroom
Rooms
Confirmation
Dataflow - domain model
50
14. Dataflow diagrams
Booking request
FindFree Room
Booking request room
Guests
Record Guest
room list
Send Confirm
Record Booking
Rooms
Data description Booking request guest data
period room type
Domain model, second level
51
14. Dataflow diagrams
Booking request
FindFreeRoom
periodroom type
User
Product
free rooms
choice
Rooms
Booking request
room
Record Guest
Current
User
Prod.
Guest data chosen room
Guests
Record Booking
User
Prod.
Dividing the work
52
14. Dataflow diagrams
The product shall handle the events as follows
Find room )
Record guest
Find guest
) Find room period room type
FindFree Room
Record Guest
Find Guest
room
Record booking or checkin
Record Booking OrCheckin
Print Confirm
Print confirm
Dataflow - product level
53
14. Dataflow diagrams

• Advantages of DFD useful for the following
• Outlining user tasks in a graphical way
• Specifying communication between technical
  components
• Designing the new human activities in the domain
• Outlining the internal structure of the program
• Validation Customers without an IT background
  can fairly easily understand DFD, particularly
  those describing domain aspects.
• Disadvantages of DFD
• DFD are not suited to describing user tasks with
  many variations
• They dont support the problem-oriented or
  cost/benefit oriented view covered by tasks and
  support.

54
15. Standards as requirements

• What is it ?
• Text requirement the product shall follow
  standard xx
• Transfers the problem to the supplier
• Sometimes leads to false sense of security
• An important type of the requirement
• Some analysts (as well as IEEE830) call such
  requirements constraints

55
15. Standards as requirements
R1 Data transfer to the account package shall be
done through a file with the format described in
WonderAccount Interface Guide xx.yy. The account
numbers shall be . . . R2 The user interface
shall follow MS Windows Style Guide, xx.yy. The
MS Word user interface should be used as a model
where appropriate. R3 Shall run under
MS-Windows release xx.yy. Supplier shall port
product to new releases within ______
months. R4 Shall follow good accounting
practice. The supplier shall obtain the necessary
certification. R5 The supplier shall update the
payroll computations in accordance with new union
agreements within one month after release of the
agreement.
56
15. Standards as requirements

• Validation Customers often rely on standards to
  ensure some unspecified goal. It is important to
  specify to specify the goal of the standard in
  each project to be able to check that the
  standard achieves the goal.
• Verification Some standards can be reasonably
  well verified before the system is put into
  operation.

57
16. Development process requirements

• What is it ?
• A requirement to follow procedure xx to find the
  real requirements
• The best way if real requirements are uncertain
• Management control and price formulas can limit
  the risks
• Some analysts insist that such project
  specifications are not part of requirements , but
  part of the contract.

58
16. Development process requirements
R1 System development shall use iterative
development based on prototypes as described in
App. xx. R2 Supplier shall deliver additional
screens with a complexity like screen S3 at a
price of ____ per screen. R3 All developers
shall spend at least two days working with the
users on their daily tasks. R4 A special review
shall be conducted at the end of each development
activity to verify that all requirements and
system goals are duly considered. The customers
representative shall participate in the
review. R5 Customer and supplier shall meet at
least two hours bi-weekly to review requests for
change and decide what to do, based on
cost/benefit estimates of the changes.
Generates new requirements?
59
16. Development process requirements

• Validation. Usually the customer has little
  understanding of how a process relates to the
  quality of the product. Most customers have
  little chance to validate that the process is
  adequate. However, the customer can validate the
  final requirements, and the purpose of the
  process is to support this.
• Verification. Quite often developers commit to a
  specific process, yet go ahead and do something
  different. Verifying that the process is carried
  out is thus important. The customer should take
  some responsibility for this, for instance by
  participating in reviews or inspecting documents.