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


Agenda



7

Tools-Driven Approaches

Agenda – Requirements Engineering Processes

Requirements Engineering Processes


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


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


Strategy Definition

Concept Definition


Business Model

Requirements


Requirements ModelCategories



Business Objective

Features and Events




Business Process

Requirements


Process Model

Requirements




Enterprise Glossary






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


Strategy Definition

Concept Definition


Business Model

Requirements





Business Objective

Features and Events




Business Process

Requirements


Process Model

Requirements




Enterprise Glossary






Relationships

Bus. Arch.

BUC Mdl

Entities

Bus. ProblemForce

Hierarchies

URN Mdl


Styles



Analysis

Org. Mdl

Loc. Mdl

Capab. Matrix


<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


Styles



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)


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


Strategy Definition

Concept Definition


Business Model

Requirements





Business Objective

Features and Events




Business Process

Requirements


Process Model

Requirements




Enterprise Glossary






Design

Relationships

Bus. Arch. Engineering

BUC Mdl

Domain ModelEntities

Bus. ProblemForce

Hierarchies

URN Mdl


Styles


Req Mdl Analysis


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)


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



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

software engineering session 4 – main theme requirements

Documents