L8 Requirements as user stories and beyond (CS5037 Systems Analysis and Design)

Nigel Beacham Department of Computing Science

Where are we now?

Software development paradigms The Unified Process (UP) paradigm
UP phases and UP disciplines (activities) within each phase Inception (first UP phase) Elaboration (second UP phase) Moving from inception to elaboration o User stories in detail (and beyond)

User stories in details quality attributes

For user stories to be good, they must have six attributes: Independence Negotiability Value to users or customers Estimability Size (small) Testability

User story independence

User stories are independent of each other; a dependency occurs when the estimate of the effort needed to develop one user story depends on the effort needed to develop a previous one Example:
The user should be able to pay the purchase using a VISA credit card The user should be able to pay the purchase using a MASTERCARD credit

card

Solving the problem for case (1) means case (2) will depend on it,

needing much less time Solution:

The user should be able to pay the purchase using a credit card

User story negotiability

User stories are short description of functionalities whose details can be negotiated with customers and system users Example:
The user should be able to pay the purchase using a credit card

Negotiation focuses on which cards to accept; this extra

info goes in a footnote Solution:

Note: accept Visa, MasterCard, American Express

User story value

User stories must be valued either by system users or by system purchasers; developer value only is not relevant Example:
User value: The user should be able to pay the purchase using a

credit card Purchaser value: All configuration information must be read from a central location for each computer in the hospital No user/Purchaser value (just developer value): The software must be written in Java

User story estimability

User stories must be clear and specific enough so that it is possible to estimate their size and thus the amount of time it takes to transform them into code Problems leading to a lack of estimate:
Developers lack domain knowledge

Developers lack technical knowledge

The story is too big

User story size

User stories must be adequately small, i.e., appropriately sized on the basis of the team, its capabilities, and the used technology
Typical size problems: The story is a composite one (i.e., an epic actually aggregating several individual user stories) The story is too complex Solution: Break down the story in simpler parts

User story testability

User stories must be testable, i.e., it must be possible to specify test cases about the functionality they describe
Typical testing issues: It must always be possible to identify in the user story specific elements to be tested Any element must be tested for both valid and for invalid inputs Tests consider the functionality they refer to as a Black Box

Requirements more in depth: the FURPS+ model

We have already distinguished between functional requirements (processes

that a system must perform and/or information it must contain) and nonfunctional requirements (behavioural properties that a system must have) Non-functional requirements are too wide and important to be collapsed under such a generic label; hence the FURPS+ model has been introduced which classifies requirements as,
Functional: ditto
Usability: human factors, help, documentation Reliability: frequency of failure, recoverability, predictability Performance: response times, throughput, accuracy, availability, resource usage Supportability: adaptability, maintainability, internationalisation, configurability

Specifying the + in FURPS+

The + in FURPS+ denotes further categories of non-functional requirements that often underpin the non-functional ilities, namely: Implementation: resource limitations (HD, RAM), languages and tools, HW, OS Interfacing: constraints imposed by the interface with other (external, often legacy) systems Operations: how to manage the system in its operational setup Packaging: how to package the system for distribution (anything from jars to a single CD-ROM with SW protection) Legal: licensing, disclaimers, IPR protection, patenting

Next lecture...
Requirements during elaboration: introducing UP use cases More specifically, we will focus on: Requirements elicitation How requirements are organised in UP artefacts The UP notion of use case