soft 423: software...

SOFT 423: Software Requirements

Week 5 Class 2

Writing Requirements and Modeling Techniques

SOFT 423 – Winter 2015 1

Last Class

•Personas

•Interactive Systems


This Class

•Writing Requirements

•Requirements Language

•Revisit Requirements Documents

•Modeling Techniques


Document Users – Who Reads?

•System Customers

•Project Managers

•System Engineers

•System testers

•System maintainers


Writing Requirements

•In general, requirements cannot be modeled•But why have we been studying models?

•Requirements are mainly text-based•Natural Language understanding



•Common Problems•complex conditions are confusing

• if A then if B then if C• tab A goes in slot B

•sloppy terminology• inconsistent terminology (signal/wait)•domain knowledge is assumed (RA/dec)



•Read more often than written•big payoff for wordsmithing

•Readers come from diverse background•use different terminology•different background knowledge



•Leave time for multiple revisions•publishing books and papers requires several revisions with the referees and/or editors, requirements are no different



•Requirements must be kept separate•Single sentence where possible

•Use present tense to state requirements

•Factor out detail•don’t remove detail, combine into lists


Some Guidelines [Sommerville & Sawyer 97]

•Define standard templates

•Use language simply, consistently and concisely

•Use diagrams appropriately•no complex diagrams•broad overviews


Some Guidelines [Sommerville & Sawyer 97]

•Supplement natural language with other descriptions (i.e. equations)

•Specify requirements quantitatively


Quantification Exercise

•Suggest methods to quantify the following requirements.



•The library system shall be easy to use



•The library system shall be easy to use

•It should be possible to train end-users of the system in a 15 minute session



•The library system provide reliable service to all classes of users



•The library system provide reliable service to all classes of users

•rate of failures less than 1 in 1000



•The library system shall provide a rapid response to all user requests



•The library system shall provide a rapid response to all user requests

•average system response time < 4 secs


Some Guidelines [Easterbrook 2002]

•Requirements are optative•Optative mood is a volitive mood that signals wishing or hoping



•Traditionally, requirements contain the word ‘shall’•contractually ‘will’ means optional!!

• ‘should’ is often code for ‘we can ignore this’

•distinction is subtle



•Bray dislikes modal verbs•difference between in house requirements and formal contractual requirements



•Verb moods•Indicative: asserts a fact (you type)•Interrogative: question (are you typing?)•Imperative: command (type!)•Subjunctive: possibility (I might type)•Optative: a wish (Had I the means, I would do it)



•For Requirements•use indicative mood for domain properties•use optative mood for requirements•do not mix moods in the same description•moods change as development progresses


Requirements Document [Bray 02]

•Primary Purpose•convey necessary information about problem domain and client’s requirementsfrom the client to the designers of the solution system


Requirements Document [Bray 02]

•Characteristics• low ambiguity•validatable•well organized•modifiable•complete•consistent


Requirements Documents

•We have already discussed IEEE standard•tends to mix problem domain descriptions and requirements•also mixes specification of solution system

•Bray suggests a different structure•explicit separation of problem domain elements from requirement elements•Problem Frames assist in the separation


Bray’s Requirements Document


Structure

•Document Details

•Problem Domain Description

•Requirements

•Data Dictionary

•References

•Index


Document Details

•similar to IEEE Section 1•title, authors•documentation conventions/standards•version•change authority•change history•content (i.e. overview of rest of document)


Problem Domain Description Overview

•summary and context

•brief overview of problem domain•should also break down into subdomains

•brief description of the project

•executive Summary


Requirements

•the real meat of the document

•broken down into categories:•Functional•Performance•Design Constraints


Data Dictionary

•reuse of term – be careful

•more general than SA Data Dictionary

•description of Data Items and Relationships


References

•elicitation notes

•stat requirements

•specifications

•target hardware

•quality assurance

•docs of pre-existing system

•development procedures


Modeling Techniques - Revisited


Modeling Techniques

•Before we discuss the specification document, we will look at modeling•used for elicitation, requirements and specification


Modeling Techniques

•Have to be careful that the Modeling does not impose constraints on the design of the solution system •external design of the system


Modeling Techniques

•We’ve already discussed several Modeling techniques:•data flow diagrams•data dictionaries•ER models•OOA diagrams


Classes of Models

•Representational Modeling

•Behavioural Modeling

•Structural Modeling


Classes of Models

•Representational Modeling•model appearance of the system•can be text•diagrams•animation


Classes of Models

•Behavioural Modeling•relationship of system inputs and outputs•some model of system state (memory)


Classes of Models

•Structural Models• less relevant, but sometimes necessary•system is modeled as components that are interconnected in some way•DFDs•We won’t cover in any more detail


Representational Modeling


Representational Modeling

•Two types:•Static Representational Modeling•Dynamic Representational Modeling


Static Representational Modeling

•simple, but effective

•often screen shots

•screen planning sheets

•can also be representations of different I/O devices such as elevator indicators, turn signals in mirrors



•Paper Prototype•draw the system on a piece of paper•major screens, menus, dialogs, wizards•extension of the back of envelope technique•cheap and effective technique both for specification and for elicitation



•Story Boards•Extension of paper prototype to time dimension•Based on movie story boards•Cartoon style sequences•Hits high points, leaves out unimportant details•still static



•What it is good for:•concepts and terminology: do target users understand terminology?•navigation and workflow•content, layout, interface functionality



•What it isn’t good for•Technical feasibility•response time


Dynamic Representational Modeling

•Operational Prototype•Iteration implied, not just user interfaces•Results of transformation system too



•Exploratory Prototype•Throwaway



•Definitive Prototype•Becomes part of definition of required behaviour



•Structural Prototype•Possible design solutions•Evaluate performance, feasibility



•Evolutionary Prototype•prototype becomes the product•start with interface and fill in functionality•relevance to requirements?


Building Prototypes

•Prototypes can also be subparts of the system•some of the other models we will be talking about can be executed and can serve the role of a prototype•can be animated

• example, simulation of finite state machine

•no longer really representational Modeling, now about functional Modeling


Building Prototypes

•Prototype may have no UI.

•May be a structural prototype of some middle component to ensure that the elements of elicitation are feasible with a given technology


Prototype Issues

•Training Costs•developers (experience building prototypes)• how to focus on what is important rather than what

needs to be explored.

•users to use the prototype


Prototype Issues

•User Expectation Management•prototypes are almost always incomplete

• is that all?

•prototypes do not include most of the business logic including multiple tiers and delays• real system will be slower


Prototype Issues

•Evaluation (UI issues)•Solitary/Supervised

• exploratory prototypes almost always supervised

•Questionnaire/Interview (both?)


Behavioural Modeling


Behavioural Modeling

•Not about appearance of system

•Some abstraction of the behaviour of the system•many different models:

• function statements, task analysis, use-cases, decision tables, finite state machines (several types), petri-charts

• informal, semi-formal, formal


Function Statements

•Text•describe causal relationship between input, system state, and output


Functional Decomposition

•functionality is broken down into lower level detail•top down methodology•Also used as normal design technique, but we focus on it’s use in specifying behaviour•functional breakdown as apparent to the user• adding invisible details implies premature design

• limited use for analysis, good for specification


Function Decomposition Example

•Student adding a course, top level•The registration system will allow a student to add a course to their program



•First Level•1 The student logs into the registration system•2 The student selects add course from the menu•3 The student selects the course to add



•Second Level•1.1 the student enters the student number•1.2 the student enters the password•1.3 the number and password is validated•1.4 if the number and password is incorrect, return to login page with error


Functional Decomposition Example

•Important things to note:•discussion of how the number and password

is validated is not discussed•not visible to the outside world•point 3 may say that only valid courses are

offered to the student to select, or that the student enters a course code, but how the system determines that the course is valid is not discussed•what a valid course would be would be

specified in another requirement


Hierarchical Task Analysis

•Human Task Performance•part of HCI•used to analyze behaviour of experts (part of task observation in elicitation)•used to guide specification and document behaviour


Hierarchical Task Analysis

•Starts with goal that someone wants to achieve•tasks are higher order mechanisms by which goals are achieved•goals may be structured as hierarchy

• break goals into subgoals

• tasks for subgoals


Class Summary


•Who reads them?

•Text-based over models•models supplement

•Document formats•IEEE vs Bray

•Language•‘shall’ not ‘will’ or ‘should’


Modeling Techniques – Revisited

•Used to supplement requirements•Classes of Models•Representational

• Static• Paper prototyping, storyboards

• Dynamic• Prototyping (operational, exploratory, definitive, structural,

evolutionary)

•Behavioural• function statements, hierarchical task analysis

•Structural

Next Class

•Formal Methods•Finite State Machines•State Transition Diagram•State Transition Matrices
