Module 3 PPT-A.pptx
Module 3 PPT-A.pptx
PROJECT MANAGEMENT
Presentation Material
Department of Computer Science & Engineering
Course Code: Semester: V
Software Engineering & Project
Course Title: Year: III
Management
Dr. Meenakshi Malhotra &
Faculty Name:
Dr Bondu Venkateswarlu
THESE SLIDES ARE DESIGNED TO ACCOMPANY SOFTWARE ENGINEERING: A PRACTITIONER’S APPROACH, 7/E
(MCGRAW-HILL, 2009). SLIDES COPYRIGHT 2009 BY ROGER PRESSMAN.
Requirements Engineering
Requirements management
.
Establishing The Groundwork
1. Identifying Stakeholders
2. Recognizing Multiple Viewpoints
3. Working toward Collaboration
4. Asking the First Questions
Establishing The Groundwork
1. Identify stakeholders
❖ “who else do you think I should talk to?”
At inception, you should create a list of people who will contribute input as
requirements are elicited
❖ Any person who benefits directly or indirectly from the system being
developed is a stakeholder.
❖ Business operations managers, product managers, marketing people, internal
and external customers, end-users, consultants, product engineers, software
engineers, and support/maintenance engineers are the usual stakeholders.
❖ Each stakeholder sees the system differently, gains different benefits when
the system is successfully developed and faces different risks if the
development effort fails.
Establishing The Groundwork
2. Recognize Multiple points of view
Because there are so many different stakeholders, the system’s requirements
will be examined from various perspectives.
Each of these stakeholders will contribute data to the requirements engineering
process. As information is gathered from multiple viewpoints, emerging
requirements may be inconsistent or contradictory.
You should categorise all stakeholder information so that decision-makers can
select an internally consistent set of system requirements for the system.
Establishing The Groundwork
3. Work toward collaboration
• If there are five stakeholders involved in a software project, there may
be five different opinions on the set of requirements.
• Customers must work together as well as with software engineering
practitioners to create a successful system.
• A requirements engineer’s job is to identify areas of commonality as
well as areas of conflict or inconsistency. Collaboration does not always
imply that requirements are set by a committee.
• In many cases, stakeholders collaborate by providing their perspective on
requirements, but a strong “project champion” may ultimately decide on
which requirements are accepted.
Establishing The Groundwork
The first questions
Who is behind the request for this work?
Who will use the solution?
What will be the economic benefit of a successful solution
Is there another source for the solution that you need?
These questions aid in identifying all stakeholders who will be
interested in the software being developed.
Moreover, the questions identify the quantifiable benefit of
successful implementation as well as potential alternatives to
custom software development.
.
Establishing The Groundwork
Our research indicates that the market for home management systems
is growing at a rate of 40 percent per year. The first SafeHome function
we bring to market should be the home security function. Most
people are familiar with “alarm systems” so this would be an easy sell.
For example, the mini-spec for the SafeHome object Control Panel might
be:
THESE SLIDES ARE DESIGNED TO ACCOMPANY SOFTWARE ENGINEERING: A PRACTITIONER’S APPROACH, 7/E
(MCGRAW-HILL, 2009). SLIDES COPYRIGHT 2009 BY ROGER PRESSMAN.
Eliciting
Requirements
Eliciting Requirements (Requirements
Gathering)
2. Quality Function Deployment(QFD)
Function deployment determines the “value” (as perceived by
the customer) of each function required of the system
Information deployment identifies data objects and events
Task deployment examines the behavior of the system
Value analysis determines the relative priority of
requirements
QFD “concentrates on maximizing customer satisfaction from the
software engineering process”
Secondary actors
❖ support the system so that primary actors can do their work.
DEVELOPING USE CASES
Jacobson [Jac92] suggests a number of questions that should be answered by a use
Case
Who is the primary actor, the secondary actor(s)?
What are the actor’s goals?
What preconditions should exist before the story begins?
What main tasks or functions are performed by the actor?
What exceptions might be considered as the story is described?
What variations in the actor’s interaction are possible?
What system information will the actor acquire, produce, or change?
Will the actor have to inform the system about changes in the external environment?
What information does the actor desire from the system?
Does the actor wish to be informed about unexpected changes?
DEVELOPING USE CASES
Basic SafeHome requirements, we define four actors (primary):
homeowner (a user),
setup manager (likely the same person as homeowner, but playing a
different role),
sensors (devices attached to the system), and
the monitoring and response subsystem (the central station that monitors
the SafeHome home security function).
DEVELOPING USE CASES
Basic SafeHome requirements, we define four actors (primary):
homeowner (a user),
setup manager (likely the same person as homeowner, but playing a
different role),
sensors (devices attached to the system), and
the monitoring and response subsystem (the central station that monitors
the SafeHome home security function).
DEVELOPING USE CASES
Secondary Actors: These are external systems or users who indirectly interact
with the home security system:
THESE SLIDES ARE DESIGNED TO ACCOMPANY SOFTWARE ENGINEERING: A PRACTITIONER’S APPROACH, 7/E
(MCGRAW-HILL, 2009). SLIDES COPYRIGHT 2009 BY ROGER PRESSMAN.
DEVELOPING USE CASES –
Restaurant
UML Use Case Diagram Example
Update profile
Category based
THESE SLIDES ARE DESIGNED TO ACCOMPANY SOFTWARE ENGINEERING: A PRACTITIONER’S APPROACH, 7/E
(MCGRAW-HILL, 2009). SLIDES COPYRIGHT 2009 BY ROGER PRESSMAN.
DEVELOPING USE CASES –
University Course Registration System
Description:
A course registration system allows students to register for courses, professors to manage
course content, and administrators to handle course scheduling.
Actors:
.
DEVELOPING USE CASES –
Use Cases:
1.Search Courses (Student)
1. Browse courses based on department, professor, or semester.
2.Register for Course (Student)
1. Add a course to the student's schedule.
3.Drop Course (Student)
1. Remove a previously registered course.
4.View Grades (Student)
1. Access grades for completed courses.
5.Manage Course Content (Professor)
1. Update course syllabus, add assignments, and upload materials.
6.Grade Students (Professor)
1. Enter grades for student assessments and assignments.
7.Schedule Courses (Registrar/Admin)
1. Plan and organize course availability for each semester.
8.Manage Student Records (Registrar/Admin)
1. Update student profiles and academic records.
Building the Analysis Model
the analysis model is a snapshot of requirements at any given time.
Class-based elements
Implied by scenarios
Behavioral elements
State diagram
Flow-oriented elements
Data flow diagram
Class Diagram
48
Class Diagrams
49
Class Diagram Example: Order System
State Diagram
Reading
Commands
System status = “ready” State name
Display msg = “enter cmd”
Display status = steady
State variables
Entry/subsystems ready
Do: poll user input panel
Do: read user input
Do: interpret user input
State activities
State diagram (state machine diagram or
statechart diagram)
an illustration of all the possible behavioral states a software system component
may exhibit and the various state changes it's predicted to undergo over the
course of its operations
•Initial state. A solid black circle that represents the initial state of a system or a class.
•States. Individual states are portrayed as boxes with rounded corners that contain the
name of the state (usually written in CamelCase).
•State actions. Any actions that a particular state is expected to invoke are designated by
a box with two sections:
•An upper section containing the name of the state and
•a lower section containing the actions it will initiate (as well as any relevant variable
names).
•Transitions. Straight lines each with an arrow at one end connect various pairs
of state boxes, providing an ordered designation of the state transitions that will
occur.
•Final state. Final state is portrayed as a large black dot with a circle around it.
State diagram
Symbols and components of state diagrams
State diagram
Bank ATM behavioral state machine UML diagram example
State diagram-Alarm System
State diagram
Analysis Patterns
▪ Pattern name: A descriptor that captures the essence of the pattern.
▪ Intent: Describes what the pattern accomplishes or represents
▪ Motivation: A scenario that illustrates how the pattern can be used to address
the problem.
▪ Forces and context: A description of external issues (forces) that can affect how
the pattern is used and also the external issues that will be resolved when the
pattern is applied.
▪ Solution: A description of how the pattern is applied to solve the problem with
an emphasis on structural and behavioral issues.
▪ Consequences: Addresses what happens when the pattern is applied and what
trade-offs exist during its application.
▪ Design: Discusses how the analysis pattern can be achieved through the use of
known design patterns.
▪ Known uses: Examples of uses within actual systems.
▪ Related patterns: On e or more analysis patterns that are related to the named
pattern because (1) it is commonly used with the named pattern; (2) it is
structurally similar to the named pattern; (3) it is a variation of the named
pattern.
Negotiating Requirements