CMPSCI520/620
”Rick Adrion 2003 (except where noted) 1
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
11 - UML & Requirements
Rick Adrion
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Scott W. Ambler , Copyright 2003 www.agilemodeling.com/
UML 2 Activity Diagrams
ßobject-oriented equivalent of flow charts and data flowdiagrams (DFDs) from structured development
ßtypically used forßbusiness process modeling
ßmodeling the logic captured by a single use case orusage scenario
ßmodeling the detailed logic of a business rule
ßcould potentially modelßthe internal logic of a complex operation
ßfar better to simply rewrite the operation so that it issimple enough that you don’t require an activity diagram
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Scott W. Ambler , Copyright 2003 www.agilemodeling.com/
Activity Diagram Notationß Initial nodeß filled circle = starting point of the
diagram, not requiredß Activity final nodeß filled circle with a border is the
ending point, can have zero ormore activity final nodes.
ß Activityß rounded rectangles represent
activities, may be physical orelectronic
ß Flow/edgeß arrows on the diagram
ß Forkß A black bar with one flow going
into it and several leaving it,parallel activity.
ß Joinß A black bar with several flows
entering it and one leaving it,denotes the end of parallelprocessing.
ßConditionß a guard which must evaluate to
true in order to traverse the node
ß Decisionß A diamond with one flow entering and
several leavingß Mergeß A diamond with several flows entering
and one leaving, all incoming flowsmust reach this point until processingcontinues, unless otherwise noted
ß Partitionß also called swimlanes, indicating
who/what is performing the activitiesß Sub-activity indicatorß rake in the bottom corner of an activity
indicates that the activity is describedby a more finely detailed activitydiagram.
ß Flow finalß circle with the X through it, process
stops at this point.ß Use caseß non-official? indication that an included
use case is being invoked.
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
University enrollment example
Scott W. Ambler , Copyright 2003 www.agilemodeling.com/
Fill outforms
Apply toUniversity
Imputforms Input
applicantinfo
Displaycreate student
screen
Checkapplicant
list
Searchfor
applicantDisplaylist of
matches
Selectapplicantfrom list
Createstudent
Enrollin
seminar[incorrect]
[correct]
[not on list]
[on list]
[no match]
[potential matches]
[not on match list] [on match list]
Must be onlist of applicants,but not in system
y
y
xapplicant
registrar
system
“Swim lanes”
CMPSCI520/620
”Rick Adrion 2003 (except where noted) 2
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
University enrollment example
Scott W. Ambler , Copyright 2003 www.agilemodeling.com/
Fill outforms
Apply toUniversity
Imputforms
Inputapplicant
info
Displaycreate
studentscreen
Verifyapplicantis on list
See ifapplicant
Is in system
Displaylist of
matches
Createstudent
[incorrect]
Basic Course
[not on list]
[on list]
[no match]
[potential matches]
[not on match list]
[on match list]
B: Forms not filled out G: Not eligible to enroll
Exisiting Use Case F: Student may be in System
H
PerformSecurityCheck
PossibleSecurity
Risk
Use-casecourse of action
AlternativeUse-casetriggered
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
University enrollment example
Scott W. Ambler , Copyright 2003 www.agilemodeling.com/
signal
time
pin
object
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
When to Use Activity Diagrams
ßUse activity diagrams when the behavior you aremodeling ...ßdoes not depend much on external events.ßmostly has steps that run to completion, rather thanbeing interrupted by events.ßrequires object/data flow between steps.ßis being constructed at a stage when you are moreconcerned with which activities happen, rather thanwhich objects are responsible for them (except partitionspossibly).
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Activity Diagram Modeling Tips
ßControl flow and object flow are not separate. Both aremodeled with state transitions.
ßDashed object flow lines are also control flow.
ßYou can mix state machine and control/object flowconstructs on the same diagram (though you probablydo not want to).
CMPSCI520/620
”Rick Adrion 2003 (except where noted) 3
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Wrap Up: Activity Diagrams
ßUse Activity Diagrams for applications that are primarilycontrol and data-driven, like business modeling …
… rather than event-driven applications like embeddedsystems.
ßActivity diagrams are a kind of state machine until UML2.0 …
… so control and object/data flow do not have separatesemantics.
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Statechart modeling
ßCaptures dynamic changes of class states – the lifehistory of the classßThese dynamic changes describe typically the behaviorof an object across several use casesßState of an object – designated by the current values ofthe object's attributesßStatechart Diagram – a bipartite graph ofßstates (rounded rectangles) andßtransitions (arrows) caused by eventsßThe concepts of states and events are the sameconcepts that we know from Activity Diagrams – thedifference is that “the states of the activity graphrepresent the states of executing the computation, notthe states of an ordinary object”
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Types of Events
ßUML defines 4 kinds of eventsßSignal EventßAsynchronous signal received
ße.g. evFlameOn
ßCall Eventßoperation call received
ße.g. op(a,b,c)
ßChange Eventßchange in value occurred
ßTime EventßRelative time elapse
ßAbsolute time arrived
ße.g. tm(PulseWidthTime)
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Types of Events
ßEvents are occurrences of interest that have bothßLocation
ßAbsolute time of occurrence
ßSignal events associate with SignalsßA Signal is a specification of an asynchronouscommunication between structural elements (e.g.objects)
ßOne type of Signal is Exception
CMPSCI520/620
”Rick Adrion 2003 (except where noted) 4
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
States and transitions
ßObjects change values of their attributes but not all suchchanges cause state transitions
ßWe construct state models for classes that haveinteresting state changes, not any state changes
ßStatechart Diagram is a model of business rulesßBusiness rules are invariable over some periods of time
ßThey are relatively independent of particular use cases
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Statecharts & Activity Diagrams
Heinrich Hussmann
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
States and transitions
Heinrich Hussmann
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Statechart Diagram
ß Normally attached to a class, but can be attached toother modeling concepts, e.g. a use case
ß When attached to a class, the diagram determineshow objects of that class react to eventsß Determines – for each object state – what action the
object will perform when it receives an eventß The same object may perform a different action for
the same event depending on the object’s stateß The action’s execution will typically cause a state
change
CMPSCI520/620
”Rick Adrion 2003 (except where noted) 5
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Statecharts
ßCapture state-dependent requirements
ßStatechart created for each state-dependent class
ßUML provides hierarchical state transition diagramsßBased on Harel statecharts
ßInformation CapturedßStatesßCapture all possible states of the class
ßEvents and conditions
ßDescribe transitions between statesßActions
ßIndicate processing that occurs on entry or exit to/from astate
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Statechart notation
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Example
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Nested submachines
CMPSCI520/620
”Rick Adrion 2003 (except where noted) 6
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Implementation diagrams
Deployment Diagram
Heinrich Hussmann
Component Diagram
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Requirements Process & Products
Market AnalysisSystems AnalysisBusiness Planning
Systems Engineering
Market NeedsBusiness Needs
System Requirements
Requirements AnalysisRequirements Definition
System Specification
Requirements DefinitionRequirements Document
Requirements Specification
Specification
Behavioral SpecificationSystem Specification
Functional SpecificationSpecification Document
Requirements Specification
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
System Planning
ßBusiness strategyßSmall organizations
ßLarge organizations
ßApproachesßStrength, Weaknesses, Opportunities, Threats (SWOT)
ßValue Chain Model (VCM)
ßBusiness Process Re-Engineering (BPR)
ßInformation Systems Architecture (ISA)
ßEffectiveness vs. efficiency
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Approaches
ßSWOTßTop-down classification, ranking and selection of projectsbased on: mission statement, internal strengths andweaknesses, external opportunities and threats, objectives,goals, strategies, and policies
ßVCMßLook at “value chain” – from raw materials to final productssold and shipped to customers and identify critical areaswhere IT can transform organization’s value chain
ßBPRßAimed at radical redesign of business processes, based onbusiness process”ownership,” and horizontally cross-cuttingprocesses with end at points of contact with customers. ITsupport enables BPR
ß ISAßA neutral architectural framework with stakeholders (planner,owner, designer, builder, subcontractor) and activities(what,how, where, who, when, why)
CMPSCI520/620
”Rick Adrion 2003 (except where noted) 7
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Systems and management levels
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
SW Requirements Defn Process
ßRequirements identification
ßIdentification of software development constraints
ßRequirements analysis
ßRequirements representation
ßRequirements communication
ßPreparation for validation of software requirements
ßManaging the requirements definition process definitionprocess.
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Source of requirements
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Requirements identification
ßelicited from people or derived from systemrequirements
ßSoftware needs -- Context analysisßdocuments why software is to be created and whycertain technical, operational, and economic feasibilitiesestablish boundary conditions
ßElicitation from people
ßDeriving from system planning requirements
ßTask analysis to develop user interface
CMPSCI520/620
”Rick Adrion 2003 (except where noted) 8
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
More steps
ßIdentification of software development constraintsßCosts, hardware/software, reliability, portability
ßRequirements analysisßAssessment of potential problems
ßClassification of requirements mandatory, desirable, andnon-essential
ßEvaluation of feasibility and risks
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Requirements representation
ßUse of modelsßA good model:ßReduces the amount of complexity that must becomprehended at one time.
ßIs inexpensive to build and modify compared to the realthing.
ßFacilitates the description of complex aspects of the realthing.
ßRoles for prototypingßprototype is not a substitute for a thorough writtenspecification
ßa system can be captured in a prototype
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
More steps
ßRequirements communicationßPresent to stakeholders for review
ßPreparation for validation of software requirementsßEstablish criteria
ßIdentify techniques to be used
ßManaging the requirements definition process definitionprocess.ßa major project management challenge.
ßan application that must support five different classes ofusers with significantly different expectations couldeasily involve a requirements definition process that isfive times more difficult than the corresponding processfor a homogeneous group
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Software Requirement Products
ßRequirements definitionßFunctional
ßNon-functional
ßInverse
ßDesign & implementation constraints
ßRequirement documentsßStandards
ß“C-requirements”
ß“D-requirements”
CMPSCI520/620
”Rick Adrion 2003 (except where noted) 9
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Customer/Developer
ßObjectivesßRanking of attributesßKey contentsß“C-requirements”ßFunctionalityß Information definitionsßCritical non-functional requirementsßCritical design constraintsßAcceptance criteria
ß“D-requirements”ßFunctionalityß Information definitionsß Interfaces to external systemsßCritical non-functional requirementsßCritical design constraintsßAcceptance criteria and tests
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Outcomes of a Good Process
ßThe buyers or usersßoften begin with only a vague idea of what they really needand with little idea of what software technology might offer.
ßa good process helps them explore and fully understand theirrequirementsßseparation of what they want and what they need
ßconstraints that might be imposed on the system by technology,organizational practices or government regulations.
ßunderstand alternatives, both technological and procedural, thatmight be considered in the proposed system
ßunderstand the tradeoffs
ßa good understanding of the implications of their decisions fiß fewer surprises
ßusers committed to the success of the project.
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Outcomes of a Good Process
ßsoftware engineers and developersßsolving the right problem for the users.ßhave clear, high-level specification of the system to be built.ßsolving a problem that is feasible from all perspectives, notonly technical but humanßcustomers will be able to use the system, like it, makeeffective use of it, and that the system will not haveundesirable side effectsßhave the trust and confidence of the customersßgained knowledge of the domain of the systemßthey have a variety of peripheral or ancillary information aboutthe system useful for making low-level tradeoffs and designdecisions.ßprevented the system from being overly specifiedßhave freedom to make implementation decisions.
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Outcomes of a Poor Process
ß buyers and users can be dissatisfiedßdevelopers did not really listen to them, or if the developers dominated
the process and tended to force their own views and interpretations onthe buyers and users.
ß a chaotic development process -- developers are missing importantinformationß requiring additional meetings with the buyers and usersßmay make the wrong decisions or tradeoffsß requirements may change more often,ßgreater need for configuration management, or in delays or wasted effort
in design and implementationß cost and schedule overruns, and sometimes failed or canceled projects.
ß developers are solving the wrong problemßguarantees the failure of the whole project
ß outcomeß loss of money for the company developing or buying the software,ß loss of reputation or credibility for the developersßa decline in the developers’ morale.
CMPSCI520/620
”Rick Adrion 2003 (except where noted) 10
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Underlying Difficulties
ßArticulation Problems
ßCommunication Barriers
ßKnowledge and Cognitive Limitations
ßHuman Behavior Issues
ßTechnical Issues
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Articulation Problems
ßaware of needs, but unable to articulate them appropriately
ßaware of a need but be afraid to articulate it
ßnot be aware of their needs
ßusers and developers different meanings for common terms
ßusers cannot don’t understand the consequences oralternatives.
ßno single person has the complete picture, no matter howarticulate a user may be
ßdevelopers may not really be listening to the users
ßdevelopers may fail to understand, appreciate, or relate to theusers
ßdevelopers overrule or dominate the users
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Communication Barriers
ßusers and developers come from different worlds and havedifferent professional vocabularies and viewsßusers - high level attributes like usability and reliabilityßdevelopers- lower-level attributes like resource utilization,algorithms, and hardware/ software tradeoffs.
ßnatural languages are inherently ambiguousßsocial interactionsßdifferent personality types and different value systems amongpeople.ßcan lead to unexpected difficulties in communicationßSIS exampleß project leader was a high-level person in the company, and he would only
talk to comparably high-level people in the university - deans and vicepresidentsß developers on the project would only talk to the IT & administrative staff in
the university who (they thought) would actually use systemß no one talked to faculty, students, and department staff
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Knowledge and Cognitive Limits
ßrequirements elicitor must have adequate domainknowledge
ßno person has perfect memory
ßinformal or intuitive statistics are frequently interpreteddifferently
ßscale and complexity
ßpreconceived approach to the solution of a problem
ß“tunnel vision”
ßimpatience
CMPSCI520/620
”Rick Adrion 2003 (except where noted) 11
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Human Behavior Issues
ßconflicts and ambiguities in the roles
ßfear that installation of the software will necessitatechange
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Technical Issues
ßcomplexity and social impact
ßchanging requirements
ßchanging software and hardware technologies
ßmany sources of requirements
ßnature or novelty of the system
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Requirements Engineering
ß requirements elicitationßthe process through which the customers, buyers, or users ofa software system discover, reveal, articulate, and understandtheir requirements.
ß requirements analysisßthe process of reasoning about the requirements that havebeen elicited; it involves activities such as examiningrequirements for conflicts or inconsistencies, combiningrelated requirements, and identifying missing requirements.
ß requirements specificationßthe process of recording the requirements in one or moreforms, including natural language and formal, symbolic, orgraphical representations; also, the product that is thedocument produced by that process.
ß requirements validationßthe process of confirming with the customer or user of thesoftware that the specified requirements are valid, correct, andcomplete.
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Requirements Elicitation
ßoften calledßidentifying, gathering, determining, formulating,extracting, or exposing
ßthese terms have different connotationsßgathering suggests that the requirements are alreadypresent somewhere and we need only bring themtogether
ßformulating suggests that we get to make them up
ßextracting and exposing suggest that the requirementsare being hidden by the users
ß some truth to all of these connotations
CMPSCI520/620
”Rick Adrion 2003 (except where noted) 12
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
A General Elicitation Procedure
ß identify relevant sources of requirements (the users).ßask them appropriate questions to gain an understanding of
their needs.ßanalyze the gathered information, looking for implications,
inconsistencies, or unresolved issues.ßconfirm your understanding of the requirements with the
users.ßsynthesize appropriate statements of the requirements.ßhow?ßdetailed processesßspecific questions or categories of questions to asßstructured meeting formatsßspecific individual or group behaviors, orßtemplates for organizing and recording information.
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Participantsß lead = software engineer (software requirements engineer)ß responsible for producing the requirements specification
ß support = other software engineers, documentation specialists, orclerical staff.ßusers = depends on applicationß IS: sales representatives, order processing personnel, shipping
department personnel, and accounting personnel. Departmentmanagers and company executivesßEmbedded System: design engineers (HW & SW), regulators,
system users, managersßProductivity tools: users of existing packages, market researchersßSIS: students, faculty, advisors, department staff, college staff,
registrars, bursars, financial aid, accountants, financial officers,admissions officers, administrators, laboratory technical staff, IT staff,human resources staff, …
ßno one person knows everything about what a software systemshould doßalways many participants in a successful requirements elicitation
effort
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
General approach
ßAskingßIdentify the appropriate person, such as the buyer oruser of the software, and ask what the requirements are.
ßObserving and inferring.ßObserve the behavior of users of an existing systemwhether manual or automated), and then infer theirneeds from that behavior.
ßDiscussing and formulatingßDiscuss with users their needs and jointly formulate acommon understanding of the requirements.
ßNegotiating with respect to a standard setßBeginning with an existing or standard set ofrequirements or features, negotiate with users which ofthose features will be included, excluded, or modified.
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
General approach
ßStudying and identifying problems.ßPerform investigations of problems to identifyrequirements for improving a system.
ßDiscovering through creative processesßFor very complex problems with no obvious solutions,employ creative processes involving developers andusers.
ßPostulatingßWhen there is no access to the user or customer, or forthe creation of an unprecedented product, use creativeprocesses or intuition to identify features or capabilitiesthat the user might want.
CMPSCI520/620
”Rick Adrion 2003 (except where noted) 13
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Traditional methods
ßInterviewing customers and domain experts
ßQuestionnaires
ßObservation
ßStudy of documents and software systems
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Interviews
ßTutorial interviewßExpert offers potential solutions and alternatives
ßFocused interviewßAnalyst prepares topics but not questions
ßStructured interviewßAnalyst prepares & follows a flexible topic structureßOpen-ended questions
ßClose-ended questions
ßCard sorting, repertory grids
ßTeachback interviewßUsers describe problem solving activity to analyst
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Interviews
ßInterviewing customers and domain experts
ßQuestions to be avoidedßOpinionated questions
ßBiased questions
ßImposing questions
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
questioning techniques
ßscenarioßsystem-specific questions
ßreflects less mature evaluation
ßquestionnaireßmore general items
ßreflects more mature evaluation practices
ßchecklistßdomain-specific
ßreflects more mature evaluation practices
CMPSCI520/620
”Rick Adrion 2003 (except where noted) 14
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Scenario
ßa specified sequence of steps involving the use ormodification of the system
ßprovides a means to characterize how well a particulararchitecture responds to the
ßdemands placed on it by those scenarios test what wenormally call modifiability
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Scenario usage -- current practice
ßFormßnarrative text
ßStructured text
ßDiagrammatic notation
ßImages
ßAnimations and simulations
ßContentßSystem context
ßSystem interaction
ßSystem internals
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Purpose of Scenarios
ßConcretize abstract models
ßScenarios instead of abstract models
ßScenario use with prototypes
ßComplexity reduction
ßAgreement and consistency
ßScenario usage with glossaries
ßReflection on static models
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
When to use scenarios
ßWhen abstract modeling failsßCost
ßInherent complexity
ßTeam issues
ßIn conjunction with prototypesßCan yield symbiotic results
ßStepsßDevelop scenarios
ßDevelop prototypes
ßValidate prototypes
ßRefine scenarios
CMPSCI520/620
”Rick Adrion 2003 (except where noted) 15
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
When to use scenarios
ßFor complexity reductionßUse-case approach
ßScenarios become a structuring device
ßFor exception handling & identification
ßFor achieving partial agreementßStakeholders have different goals & interests
ßUse scenarios to drive the agreement process
ßIn conjunction with glossariesßEstablish a common understanding of terms
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Questionnaire
ßa list of general and relatively open questions that applyto all systems
ßhow the requirements were generated and documented
ßdetails of the requirements descriptionßuser interface aspects separated from functionalaspects?
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Checklist
ßa more detailed set of questions that is developed aftermuch experience evaluating a common (usuallydomain-specific) set of systems.
ßhelp keep a balanced focus on all areas of the system
ßmore focused on particular qualities of the system thanquestionnairesße.g., performance questions in a real-time informationsystemß is the system writing the same data multiple times to disk?
ßhas consideration been given to handling peak as well asaverage loads?
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Questionnaires & Observation
ßQuestionnairesßIn addition to interviews
ßClose-ended questionsßMultiple-choice questions
ßRating questions
ßRanking questions
ßObservationßPassive
ßActive
ßCarried for a prolonged period of time
ßPeople tend to behave differently
CMPSCI520/620
”Rick Adrion 2003 (except where noted) 16
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Other
ßStudy of documents and software systemsßUse case requirementsßOrganizational documents
ßSystem forms and reports
ßDomain knowledge requirementsßDomain journals and reference books
ßERPS-s
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Modern methods
ßPrototyping
ßJoint Application Development (JAD)
ßRapid Application Development (RAD)
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
simulations, prototypes, etc
ßmay help to create and to clarify the requirements
ßperformance models are an example of a simulation
ßsimulation or prototype may answer an issue raised by aquestioning techniqueße.g., what evidence do you have to support thisassertion?
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Prototyping
ßstrategiesßthrow-away prototype
ßevolutionary prototype
ßadvantages
ßusers may be better able to understand and express theirneeds by comparing to an existing or reference system
ßprocessß iterative process of building a prototype and evaluating it withthe users.
ßeach iteration allows the users to understand theirrequirements better, including understanding the implicationsof the requirements articulated in previous iterations.
ßeventually, a final set of requirements can be formulated andthe prototypes discarded.
CMPSCI520/620
”Rick Adrion 2003 (except where noted) 17
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Prototyping
ßdistinguish the terms prototype and mock-up,ßA prototype demonstrates behavior of a part of the desiredsystem,ßA mock-up demonstrates the appearance of the desiredsystemßmock-ups of user interfaces are especially common.
ßbeneficial only if the prototype can be built substantially fasterthan the actual systemßprototyping should not be viewed as a euphemism for trial-
and-error programming or “hacking.”ßprototyping is properly used to elicit and understand
requirements, followed by a structured and managed processto build the actual systemßuseful in overcoming articulation problems and
communication barriers.
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Cleanroom method
Customer/UserFeedback
Customer
Complete system
Increment 1• Sign on/off• setup
Increment 2• Sign on/off• Setup• Panel navigation
Increment 3• Sign on/off• Setup• Panel navigation• Primary functions Increment 4
• Sign on/off• Setup• Panel navigation• Primary functions• Secondary functions
Requirements
Top Level Specs
IncrementalDevelopment Plan
NewReusedStubbed
Customer