Software Engineering Session 4 – Main Theme Requirements ...
Transcript of Software Engineering Session 4 – Main Theme Requirements ...
1
Software Engineering
Session 4 – Main ThemeRequirements Model Engineering
Dr. Jean-Claude Franchitti
New York UniversityComputer Science Department
Courant Institute of Mathematical Sciences
2
22 Requirements Model EngineeringRequirements Model Engineering
Agenda
11 Session OverviewSession Overview
33 Summary and ConclusionSummary and Conclusion
3
What is the class about?
Course description and syllabus:» http://www.nyu.edu/classes/jcf/g22.2440-001/
» http://www.cs.nyu.edu/courses/spring10/G22.2440-001/
Textbooks:» Software Engineering: A Practitioner’s Approach
Roger S. PressmanMcGraw-Hill Higher InternationalISBN-10: 0-0712-6782-4, ISBN-13: 978-00711267823, 7th Edition (04/09)
» http://highered.mcgraw-hill.com/sites/0073375977/information_center_view0/» http://highered.mcgraw-
hill.com/sites/0073375977/information_center_view0/table_of_contents.html
4
Requirements Model Engineering in Brief
Requirements Engineering ProcessesTools-Driven ApproachesSummary and Conclusion
ReadingsIndividual Assignment #1 (due)Team Assignment #1 (ongoing)Course Project (ongoing)
5
Icons / Metaphors
5
Common Realization
Information
Knowledge/Competency Pattern
Governance
Alignment
Solution Approach
6
22 Requirements Model EngineeringRequirements Model Engineering
Agenda
11 Session OverviewSession Overview
33 Summary and ConclusionSummary and Conclusion
7
Tools-Driven Approaches
Agenda – Requirements Engineering Processes
Requirements Engineering Processes
22 Requirements Model EngineeringRequirements Model Engineering
8
Gathering Information - Key Ideas
The goal of the analysis phase is to truly understand the requirements of the new system and develop a system that addresses them -- or decide a new system isn’t needed.The line between systems analysis and systems design is very blurry.
9
Gathering – Information Overview
InterviewsJoint Application Design (JAD)QuestionnairesDocument AnalysisObservation
10
Interviews - Five Basic Steps
Selecting IntervieweesDesigning Interview QuestionsPreparing for the InterviewConducting the InterviewPost-Interview Follow-up
11
Selecting Interviewees
Based on Information NeededOften Good to Get Different Perspectives
ManagersUsersIdeally, All Key Stakeholders
12
Types of Questions
Types of Questions Examples
Closed-Ended Questions * How many telephoneorders are received per day?
* How do customers place orders?* What additional information
would you like the new systemto provide?
Open-Ended Questions * What do you think about the current system?
* What are some of the problemsyou face on a daily basis?
* How do you decide what types ofmarketing campaign to run?
Probing Questions * Why?* Can you give me an example?* Can you explain that in a bit
more detail?
13
Designing Interview Questions
Unstructured interviewBroad, Roughly Defined Information
Structured interview More Specific Information
14
Questioning Strategies
High LevelVery General
Medium-LevelModeratelySpecific
Low-LevelVery Specific
TOP DOWN
BOTTOM UP
EXAMPLES?
15
Interview Preparation Steps
Prepare General Interview PlanList of QuestionAnticipated Answers and Follow-Ups
Confirm Areas of KnowledgeSet Priorities in Case of Time ShortagePrepare the Interviewee
ScheduleInform of Reason for InterviewInform of Areas of Discussion
16
Conducting the Interview
Appear professional and unbiasedRecord all informationCheck on organizational policy regarding tape recordingBe sure you understand all issues and termsSeparate facts from opinionsGive interviewee time to ask questionsBe sure to thank the intervieweeEnd on time
17
Conducting the Interview - Practical Tips
Don’t Worry, Be HappyPay AttentionSummarize Key PointsBe SuccinctBe HonestWatch Body Language
18
Post-Interview Follow-Up
Prepare Interview NotesPrepare Interview ReportLook for Gaps and New Questions
19
Interview Report
INTERVIEW REPORT
Interview notes approved by: ____________
Person interviewed ______________Interviewer _______________Date _______________Primary Purpose:
Summary of Interview:
Open Items:
Detailed Notes:
20
JAD: Introduction
Invented by IBM late 1970sStructured Meeting of 10-20 users~30 minutes per agenda itemfrequent breaks
21
JAD : Overview
Selecting participantsDesigning the sessionPreparing for the sessionConducting the sessionFollow-Up
22
JAD Key Ideas
Allows project managers, users, and developers to work togetherMay reduce scope creep by 50%Avoids requirements being too specific or too vague
23
Joint Application Design (JAD) Important Roles
FacilitatorScribe
24
Joint Application Design (JAD) Setting
U-Shaped seatingAway from distractionsWhiteboard/flip chartPrototyping toolse-JAD
25
JAD Meeting Room
JPEG Figure 5-5 Goes Here
26
The JAD Session
Tend to last 5 to 10 days over a three week periodPrepare questions as with interviewsFormal agenda and ground rulesFacilitator activities
Keep session on trackHelp with technical terms and jargonRecord group inputHelp resolve issues
Post-session follow-up
27
Managing Problems in JAD Sessions
Reducing dominationEncouraging non-contributorsSide discussionsAgenda merry-go-roundViolent agreementUnresolved conflictTrue conflictUse humour
28
JAD : Summary
Structured MeetingFacilitator and scribe + 10-20 usersAttempts to overcome usual problems with groupsOnly one person talks at onceEvery opinion is valued
29
Questionnaire Steps
Selecting participantsUsing samples of the population
Designing the questionnaireCareful question selection
Administering the questionnaireWorking to get good response rate
Questionnaire follow-upSend results to participants
30
Good Questionnaire Design
Begin with non-threatening and interesting questions
Group items into logically coherent sections
Do not put important items at the very end of the questionnaire
Do not crowd a page with too many items
Avoid abbreviations
Avoid biased or suggestive items or terms
Number questions to avoid confusion
Pretest the questionnaire to identify confusing questions
Provide anonymity to respondents
31
Document Analysis
Provides clues about existing “as-is” systemTypical documents
FormsReportsPolicy manuals
Look for user additions to formsLook for unused form elements
32
Observation
Users/managers often don’t remember everything they doChecks validity of information gathered other waysBehaviours change when people are watchedCareful not to ignore periodic activities
Weekly … Monthly … Annual
33
Criteria for Selecting the Appropriate Techniques
Type of informationDepth of informationBreadth of informationIntegration of informationUser involvementCostCombining techniques
34
Selecting the Appropriate Techniques
Interviews JAD Questionnaires Document ObservationAnalysis
Type of As-Is As-Is As-Is As-Is As-IsInformation Improve. Improve. Improve.
To-Be To-Be
Depth of High High Medium Low LowInformation
Breadth of Low Medium High High LowInformation
Integration Low High Low Low Lowof Info.
User Medium High Low Low LowInvolvement
Cost Medium Low- Low Low Low-Medium Medium
35
Tools-Driven Approaches
Agenda – Requirements Engineering Processes
Requirements Engineering Processes
22 Requirements Model EngineeringRequirements Model Engineering
36
Sub-Section Objectives
Describe Requirements Model Engineering Activities for a Selected Tools-Driven Approach
37
EAMF Requirements Model Engineering
Traceable Artifacts
38
Requirements and Definitions Traceability Graph
39
Reasoning About Business Entities and Their Dependencies and Goals
40
Pattern Language Structure for Agent Patterns Selection(http://www.scs.carleton.ca/~weiss/papers/aois03-revised.pdf)
41
Requirements Model Engineering Activities
Document New Requirements Traceability
Document Traceability
Between Modeling Constructs and
Req. Model Definitions
Map Business Requirements into
Requirements Model
<analysis input> Project
Requirements
Document Traceability
between Project Requirements and
Req. Model Definitions/
Requirements
Draw Actor and Dependency Diagram(s)
Draw Goal and Task Diagram(s)
Document Modeling
Constructs
Populate Requirements
Model Categories
Sparx Systems EA
EAMF CatalogSparxSystems EARepository ReqPro
Reqs Repository
Shared File System
Business Analyst Business Architect
1 2 3
4
5
ReqPro JUCMNav
ReqPro
<definition>all<requirement>some
Def(s) and Req(s)Traceability Info <requirement>
Business Entity
EAMF ProcessPatterns
EAMF ProcessPatterns
<requirement>Business Entity
<requirement>Business Entity
<requirement>Business Use Case
<requirement>Organizational<requirement>Location
6
7
8
Def
Req
Req
Modeling ConstructsTo Req. Model Defs
TraceabilityInformation
Legend:
1. ReqPro Doc(s)
2. ReqPro Req(s)
3. ReqPro Traceab. Info*
4. EA Doc Ref(s)*
5. EA Def(s)
6, EA Req(s)
7. EA Traceab. Info*
8. jUCMNav Diagram
9. EAMF Patterns
Def
Req
Def Req
Req
Req(s) Traceability Info
42
Use of Sparx Systems EA to Engineer an EAMF Requirements Model
Project Bus. Vocabulary Definition
Strategy Definition
Concept Definition
Business Use Case Requirements
Business Model
Requirements
Requirements Definition
Project Requirements ModelCategories
RequirementsModel Engineering
Proj. Bus. Directives
Business Objective
Features and Events
Functional Requirements
Non-Functional Requirements
Business Entity Requirements
Business Process
Requirements
Bus/Workflow Rules Reqs
Process Model
Requirements
Location Requirements
Organizational Requirements
EAMF Catalogs and Enterprise Requirements Model Categories
Enterprise Glossary
Enterprise Business Rules
Enterprise Solution Patterns
Enterprise Strategies
Pattern/Product/Enterprise Solutions Catalog
Enterprise Projects (e.g., Ent. Worker Services)
<analysis input> Requirements ModelWithin EA EAMF- Compliant Project
Template
<definition> Project Business Vocabulary
<definition> Strategy Definition
<definition> Concept Definition
<requirement> Business Entity Requirements
<requirement> Business Use Case Requirements
<requirement> Business Model Requirements
<requirement> Requirements Definition
EAMF Pattern, Product and Enterprise Solutions Catalogs
EAMF Enterprise Requirements Model
Enterprise Projects(EAMF-Compliant)
43
Sparx Systems EA Template
44
Use of IBM Rational ReqPro for the Requirements Model Engineering Phase
Ente
rpris
e P
roje
ct R
eqs
Mod
el ty
pes
are
the
sam
e as
Pro
ject
Req
s M
odel
Typ
es
Enterprise P
roject Req M
odel Docs types are the sam
e as Project R
eq Model D
ocs Types
45
jUCMNav GRL Modeling Constructs(http://www.scs.carleton.ca/~weiss/papers/MCeTech05.pdf)
46
jUCMNav GRL Modeling Constructs (continued)(http://www.jrpit.acs.org.au/jrpit/JRPITVolumes/JRPIT36/JRPIT36.4.259.pdf)
47
jUCMNav User Interface
48
Sample Actor-Dependency Diagram(Early Requirements Discipline)
49
Business Architecture Analysis Using EAMF
Software Development Lifecycle Phases
Project Bus. Vocabulary Definition
Strategy Definition
Concept Definition
Business Use Case Requirements
Business Model
Requirements
Requirements Definition
Requirements ModelCategories
RequirementsModel Engineering
Proj. Bus. Directives
Business Objective
Features and Events
Functional Requirements
Non-Functional Requirements
Business Entity Requirements
Business Process
Requirements
Bus/Workflow Rules Reqs
Process Model
Requirements
Location Requirements
Organizational Requirements
EAMF Catalogs and Enterprise Requirements Model Categories
Enterprise Glossary
Enterprise Business Rules
Enterprise Solution Patterns
Enterprise Strategies
Pattern/Product/Enterprise Solutions Catalog
Enterprise Projects (e.g., Ent. Worker Services)
Relationships
Bus. Arch.
BUC Mdl
Entities
Bus. ProblemForce
Hierarchies
URN Mdl
Candidate Bus. Arch.
Styles
CandidateReferenceProjects
Req Mdl Analysis
Bus. Arch.Analysis Artifacts
Analysis
Org. Mdl
Loc. Mdl
Capab. Matrix
Candidate Bus Pattern Hierarchies
50
Pattern Language Structure for Agent Patterns Selection
High-LevelBusiness Requirements
(bus. obj. & informal reqs)
Modeled by
Business Model Reqs(org, location, process)
Represented In Terms of
Value Flows Between Actors Indicate
Business Process Activities Reqs
Refined Into
Business Process Reqs
Part of
Described By
Motivated By
Have
Have(Based on Goals Achievement)
High-LevelTasks
Refined into
Refined into
Path SegmentsPlug-in Maps Couplings Between Paths
Meet
Described By
(Teams) Components
Allocated to
RolesAllocated to(based on belief)
Applied to
Implemented viaContain
Motivates
Newly Identified Requirements
Leads to
Modeled by
Low-Level Responsibilities
Scenario Definitions
Goals & Subgoals
Actors
Dependencies
1
1
2
3
4
4
5
: GRL Modeling Constructs
: UCM Modeling Constructs
Legend:
EAMF Process PatternsHelp Engineer
HelpEngineer
Assigned to
51
UCM Notations Summarized(http://www.usecasemaps.org/pub/sugarloafplop01.pdf)
Figure 27
52
UCM Notations Summarized (continued)(http://www.scs.carleton.ca/~francis/Thesis/phdthesis.pdf)
53
Inter-Scenario Relationships Design Patterns Used in EAMF BPM Approach(http://jucmnav.softwareengineering.ca/twiki/pub/UCM/VirLibIsorc2000/isorc2000.pdf, http://www.scs.carleton.ca/~francis/Thesis/phdthesis.pdf)
54
Combining Goal Oriented & Scenario-Based Modeling(http://www.cs.toronto.edu/km/GRL/from-r2a/fromr2a/straw01.pdf)
55
Use of Sparx Systems EA to Analyze the Business Architecture
Project Bus. Vocabulary Definition
Strategy Definition
Concept Definition
Business Use Case Requirements
Business Model
Requirements
Requirements Definition
Requirements ModelCategories
RequirementsModel Engineering
Proj. Bus. Directives
Business Objective
Features and Events
Functional Requirements
Non-Functional Requirements
Business Entity Requirements
Business Process
Requirements
Bus/Workflow Rules Reqs
Process Model
Requirements
Location Requirements
Organizational Requirements
EAMF Catalogs and Enterprise Requirements Model Categories
Enterprise Glossary
Enterprise Business Rules
Enterprise Solution Patterns
Enterprise Strategies
Pattern/Product/Enterprise Solutions Catalog
Enterprise Projects (e.g., Ent. Worker Services)
Relationships
Bus. Arch.
BUC Mdl
Entities
Bus. ProblemForce
Hierarchies
URN Mdl
Candidate Bus. Arch.
Styles
CandidateReferenceProjects
Bus. Arch.Analysis Artifacts
Analysis
Org. Mdl
Loc. Mdl
Capab. Matrix
Candidate Bus Pattern Hierarchies
<analysis input> Requirements ModelWithin EA EAMF- Compliant Project
Template
<definition> Business Vocbulary
<definition> Strategy Definition
<definition> Concept Definition
<requirement> Business Entity Requirements
<requirement> Business Use Case Requirements
<requirement> Business Model Requirements
<requirement> Requirements Definition
<view> Analysis within <perspective> Business Architecture of EAMF-
Compliant Project Template
EAMF Pattern, Product and Enterprise Solutions Catalogs
EAMF Enterprise Requirements Model
Enterprise EAMF-Compliant Project
Within EAMF Framework
Within EAMF Enterprise Solutions Catalog
56
Business Architecture Design Using EAMF
Software Development Lifecycle PhasesDesign
Relationships
Bus. Arch. Engineering
BUC Mdl
Domain ModelEntities
Bus. ProblemForce
Hierarchies
URN Mdl
Candidate Bus. Arch.
Styles
CandidateReferenceProjects
Bus. Arch.Analysis Artifacts
Bus. Arch.Design Artifacts
Analysis
Org. Mdl
Loc. Mdl
BUC Mdl
Loc. Mdl
Org. Mdl
Process Mdl
Capab. Matrix
ReferenceEAMF
Project(s)
Reference BusinessArch(s)
Candidate Bus Pattern Hierarchies
Bus. Pattern Hierarchies
Bus. Arch.Model
Bus. Arch.Patterns/Reuse
Constraints
57
Use of Sparx Systems EA to Design the Business Architecture
58
From Requirements Engineering to BA Engineering Using EAMF
Glossary
Stakeholder Requests
Business Objectives
Features and Events
Use Cases
Business Model
Business or Functional Requirements
Non Functional Requirements
Requirements Types
Software Development Lifecycle Phases
Requirements Engineering
Location
Organization
ProcessBusiness
Rules
Pattern/Product/Enterprise Solution Reqs
Business Rules Reqs Repository
Enterprise Solution Patterns Requirements
Enterprise Business Vocabulary Reqs
Business Strategy and Innovation Reqs
Enterprise Requirements
Enterprise Project Requirements
Req. Analysis
WorkflowRules
Project Bus. Vocabulary Definition
Strategy Definition
Concept Definition
Business Use Case Requirements
Business Model
Requirements
Requirements Definition
Requirements ModelCategories
RequirementsModel Engineering
Proj. Bus. Directives
Business Objective
Features and Events
Functional Requirements
Non-Functional Requirements
Business Entity Requirements
Business Process
Requirements
Bus/Workflow Rules Reqs
Process Model
Requirements
Location Requirements
Organizational Requirements
EAMF Catalogs and Enterprise Requirements Model Categories
Enterprise Glossary
Enterprise Business Rules
Enterprise Solution Patterns
Enterprise Strategies
Pattern/Product/Enterprise Solutions Catalog
Enterprise Projects (e.g., Ent. Worker Services)
Design
Relationships
Bus. Arch. Engineering
BUC Mdl
Domain ModelEntities
Bus. ProblemForce
Hierarchies
URN Mdl
Candidate Bus. Arch.
Styles
CandidateReferenceProjects
Req Mdl Analysis
Bus. Arch.Analysis Artifacts
Bus. Arch.Design Artifacts
Analysis
Org. Mdl
Loc. Mdl
BUC Mdl
Loc. Mdl
Org. Mdl
Process Mdl
Capab. Matrix
ReferenceEAMF
Project(s)
Reference BusinessArch(s)
Candidate Bus Pattern Hierarchies
Bus. Pattern Hierarchies
Bus. Arch.Model
Bus. Arch.Patterns/Reuse
Constraints
59
Actor/Dependency and Goal/Plan Diagram (Late Requirements Discipline)
60
Actor/Dependency Diagrams (Late Requirements Discipline)
61
Composite UCM Root Map for ESLM
62
Plug-In Map for HandleAllEvents in Root Map
63
Generic Plug-In Map for HandlePolicyServiceEvents and HandleInvoiceServiceEvents
64
Generic Plug-In Map for ProcessAllRequests Stub in Root Map
65
22 Planning and Managing RequirementsPlanning and Managing Requirements
Agenda
11 Session OverviewSession Overview
33 Summary and ConclusionSummary and Conclusion
66
Conclusions: Gathering Information & Tools-Driven Approach
Gathering Information InvolvesInterviewsJoint Application Design (JAD)QuestionnairesDocument AnalysisObservation
Tools-Driven Approach InvolvesRequirements Engineering ToolsUsers and Goals Elicitation ToolUse Case Maps
67
Course Assignments
Individual AssignmentsReports based on case studies / class presentations
Project-Related AssignmentsAll assignments (other than the individual assessments) will correspond to milestones in the team project.As the course progresses, students will be applying various methodologies to a project of their choice. The project and related software system should relate to a real-world scenario chosen by each team. The project will consist of inter-related deliverables which are due on a (bi-) weekly basis.There will be only one submission per team per deliverable and all teams must demonstrate their projects to the course instructor.A sample project description and additional details will be available under handouts on the course Web site
68
Team Project
Project LogisticsTeams will pick their own projects, within certain constraints: for instance, all projects should involve multiple distributed subsystems (e.g., web-based electronic services projects including client, application server, and database tiers). Students will need to come up to speed on whatever programming languages and/or software technologies they choose for their projects - which will not necessarily be covered in class.Students will be required to form themselves into "pairs" of exactly two (2) members each; if there is an odd number of students in the class, then one (1) team of three (3) members will be permitted. There may not be any "pairs" of only one member! The instructor and TA(s) will then assist the pairs in forming "teams", ideally each consisting of two (2) "pairs", possibly three (3) pairs if necessary due to enrollment, but students are encouraged to form their own 2-pair teams in advance. If some students drop the course, any remaining pair or team members may be arbitrarily reassigned to other pairs/teams at the discretion of the instructor (but are strongly encouraged to reform pairs/teams on their own). Students will develop and test their project code together with the other member of their programming pair.
69
Document Transformation methodology driven approach
Strategy Alignment Elicitation Equivalent to strategic planning
i.e., planning at the level of a project set
Strategy Alignment ExecutionEquivalent to project planning + SDLC
i.e., planning a the level of individual projects + project implementation
Build a methodology Wiki & partially implement the enablersApply transformation methodology approach to a sample problem domain for which a business solution must be foundFinal product is a wiki/report that focuses on
Methodology / methodology implementation / sample business-driven problem solution
Team Project Approach - Overall
70
Document sample problem domain and business-driven problem of interest
Problem descriptionHigh-level specification detailsHigh-level implementation detailsProposed high-level timeline
Team Project Approach – Initial Step
71
Assignments & Readings
Readings
Slides and Handouts posted on the course web site
Textbook: Part Two-Chapter 5Individual Assignment (due)
See Session 3 Handout: “Assignment #1”
Team Project #1 (ongoing)
Team Project proposal (format TBD in class)
See Session 2 Handout: “Team Project Specification” (Part 1)
Team Exercise #1 (ongoing)
Presentation topic proposal (format TBD in class)Project Frameworks Setup (ongoing)
As per reference provided on the course Web site
72
Any Questions?
73
Next Session: Introduction to Software Analysis and Design