2
The scope of RE: the WHY, WHAT, WHO dimensions Objectives WHY a new system? WHAT services? WHO will be responsible for what ? satisfy assignment requirements, constraints, assumptions problems,opportunities, system knowledge System-to-be System-as-is

5
The WHO dimension  Assign responsibilities for the objectives, services, constraints among system-to-be components –based on their capabilities and on the system’s objectives –yielding the software-environment boundary  Example: airport train control or –“Safe train acceleration”... under direct responsibility of software-to-be (driverless option) or of driver following software indications ? or –“Accurate estimation of train speed/position”... under responsibility of tracking system or of preceding train ?  Difficulties –Evaluate alternative options to decide on the right degree of automation ?

6
Statements about the System  Descriptive  Descriptive statements state system properties holding regardless of how the system should behave (indicative mood) –natural law, physical constraint, etc –e.g. “If train doors are closed, they are not open” “If the train’s acceleration is positive, its speed is non-null”  Prescriptive  Prescriptive statements state desirable properties holding or not depending on how the system behaves (optative mood) e.g. “Doors shall always remain closed when the train is moving”  Important distinction for RE: –prescriptive statements can be negotiated, weakened, replaced by alternatives –descriptive statements cannot

7
Statements may differ in scope A RE statement may refer to phenomena... –owned by the environment controls monitored –or shared between the environment & the software-to-be: one controls phenomena monitored by the other, and resp.

8
systemsoftware Types of statements: system requirements, software requirements  System requirement  System requirement: prescriptive statement refering to environment phenomena (not necessarily shared) –to be enforced by the software-to-be possibly together with other system components –formulated in a vocabulary understandable by all parties  TrainMoving  DoorsClosed  Software requirement  Software requirement: prescriptive statement refering to shared phenomena –to be enforced by the software-to-be solely –formulated in the vocabulary of software developers  measuredSpeed  0  doorsState = 'closed’ (A software req is a system req; the converse is not true)

22
Errors in a requirements document (RD)  Omission  Omission: problem world feature not stated by any RD item e.g. no req about state of train doors in case of emergency stop  Contradiction  Contradiction: RD items stating a problem world feature in an incompatible way “Doors must always be kept closed between platforms” and “Doors must be opened in case of emergency stop”  Inadequacy  Inadequacy: RD item not adequately stating a problem world feature “Panels inside trains shall display all flights served at next stop”  Ambiguity  Ambiguity: RD item allowing a problem world feature to be interpreted in different ways “Doors shall be open as soon as the train is stopped at platform”  Unmeasurability  Unmeasurability: RD item stating a problem world feature in a way precluding option comparison or solution testing “Panels inside trains shall be user-friendly”

24
Flaws in a requirements document (2)  Forward reference  Forward reference: RD item making use of problem world features not defined yet Multiple uses of the concept of worst-case stopping distance before its definition appears several pages after in the RD  Remorse  Remorse: RD item stating a problem world feature lately or incidentally After multiple uses of the undefined concept of worst-case stopping distance, the last one directly followed by an incidental definition between parentheses  Poor modifiability  Poor modifiability: RD items whose changes must be propagated throughout the RD Use of fixed numerical values for quantities subject to change  Opacity  Opacity: RD item whose rationale, authoring or dependencies are invisible “The commanded train speed must always be at least 7 mph above physical speed” without any explanation of rationale for this

36
Scenarios & storyboards  Goal  Goal: acquire or validate info from concrete examples through narratives... –how things are running in the system-as-is –how things should be running in the system-to-be  Storyboard  Storyboard: tells a story by a sequence of snapshots –Snapshot = sentence, sketch, slide, picture, etc. –Possibly structured with annotations: WHO are the players, WHAT happens to them, WHY this happens, WHAT IF this does / does not happen, etc –Passive –Passive mode (for validation) : stakeholders are told the story –Active –Active mode (for joint exploration) : stakeholders contribute

38
Scenario example: meeting scheduling initiatorscheduler 1. The initiator asks the scheduler for planning a meeting within some date range. The request includes a list of desired participants. scheduler initiator 2. The scheduler checks that the initiator is entitled to do so and that the request is valid. It confirms to the initiator that the requested meeting is initiated. schedulerparticipant 3. The scheduler asks all participants in the submitted list to send their date and location constraints back within the prescribed date range. participantscheduler It participant 4. When a participant returns her constraints, the scheduler validates them (e.g., with respect to the prescribed date range). It confirms to the participant that the constraints have been safely received. scheduler 5. Once all valid constraints are received, the scheduler determines a meeting date and location that fit them. scheduler initiatorparticipant 6. The scheduler notifies the scheduled meeting date and location to the initiator and to all invited participants

45
Reuse of domain-independent knowledge: requirements taxonomies  For each leaf node in available req taxonomies: “Is there any system-specific req instance from this class?”  More specific taxonomy => more focussed search mean number of meetings to be scheduled at peak times ? response time for... participant constraints ? meeting scheduling ? meeting notification ?

54
Guidelines for effective interviews  Identify the right interviewee sample for full coverage of issues –different responsibilities, expertise, tasks, exposure to problems  Come prepared, to focus on right issue at right time –backgound study first this –predesign a sequence of questions for this interviewee  Centre the interview on the interviewee’s work & concerns  Keep control over the interview  Make the interviewee feel comfortable –Start: break ice, provide motivation, ask easy questions –Consider the person too, not only the role –Do always appear as a trustworthy partner

55
Guidelines for effective interviews (2)  Be focused, keep open-ended questions for the end  Be open-minded, flexible in case of unexpected answers  Ask why-questions without being offending  Avoid certain types of questions... –opiniated or biased –affirmative –obvious or impossible answer for this interviewee  Edit & structure interview transcripts while still fresh in mind –including personal reactions, attitudes, etc  Keep interviewee in the loop –co-review interview transcript for validation & refinement Model-driven interviews may help structure them (see Part 2 of the book)

56
Observation & ethnographic studies task  Focus on task elicitation in the system-as-is  Understanding a task is often easier by observing people performing it (rather than verbal or textual explanation) –cf. tying shoelaces  Passive  Passive observation: no interference with task performers –Watch from outside, record (notes, video), edit transcripts, interpret –Protocol analysis –Protocol analysis: task performers concurrently explain it –Ethnographic studies –Ethnographic studies: over long periods of time, try to discover emergent properties of social group involved about task performance + attitudes, reactions, gestures,...  Active  Active observation: you get involved in the task, even become a team member

57
Observation & ethnographic studies: pros & cons May reveal... –tacit knowledge –tacit knowledge that would not emerge otherwise e.g. ethnographic study of air traffic control => implicit mental model of air traffic to be preserved in system-to-be –hidden problems through tricky ways of doing things –culture-specific aspects to be taken into account Contextualization of acquired info  Slow & expensive: to be done over long periods of time, at different times, under different workload conditions  Potentially inaccurate (people behave differently when observed)  Data mining problem, interpretation problem  Focus on system-as-is Some of the interviewing guidelines are relevant

58
Group sessions  More perception, judgement, invention from interactions within group of diverse people  Elicitation takes place in series of group workshops (a few days each) + follow-up actions audiovisuals, wall charts to foster discussion, record outcome  Structured  Structured group sessions: –Each participant has a clearly defined role (leader, moderator, manager, user, developer,...) –Contributes to req elaboration according to his/her role, towards reaching synergies –Generally focused on high-level reqs –Variants: focus groups, JAD, QFD,...

59
Group sessions (2)  Unstructured  Unstructured group sessions (brainstorming): –Participants have a less clearly defined role –Two separate stages... Idea generation 1. Idea generation to address a problem: as many ideas as possible from each participant without censorship/criticism Idea evaluation 2. Idea evaluation: by all participants together according to agreed criteria (e.g. value, cost, feasibility) to prioritize ideas