Beruflich Dokumente
Kultur Dokumente
Goals
Reduce waste
Complete projects on time
Improve efficiency
Document the right requirements
Software
Engineering
Software Engineering
20
Software Development Life Cycle
Otherwise called software
development process
SDLC -Building the system
Steps
Feasibility Study
Analysis
Design
Development
Testing
Implementation
Maintenance
Software Development Processes
Waterfall Model:
After each step is finished, the process
proceeds to the next step.
Continued.
Iterative development:
Construction of initially small but ever larger
portions of a software project
Agile
Extreme Programming
Scrum
Others
Rational Unified Process
Re-engineering
Re-design and/or re-implementation of an
existing system using newer
technology
Triggered by technology enabler
Interface Engineering
Provide the services of an existing system in a
new environment
Project Life Cycle
Project Initiation
Turn an idea or work request into a defined project by
specifying scope and objectives, identifying resources,
and determining project approach and milestones.
Steps in Initiation
Client Project Meeting: Initial meeting with the client
to discuss what they would like to accomplish,
timing, etc.
Project Definition (also known as a 'Project
Charter')/Project Proposal: A document that
describes the purpose, objectives, scope and
deliverables of the project
Project Approach (also known as a 'Project Life
Cycle'): A document that describes the phases, kinds
of results, and major review points of the project
Project Scope
Scope defines what is or is not included in the
project and controls what gets added or
removed as the project proceeds.
Project changes that impact scope include:
requirements, constraints, assumptions and
risk
Business Opportunity/Problem
Identify and document business
process to understand what is being
built
This is a critical activity in any
project
Business Architecture Workflow
Business Process model helps
understand the business
environment
Captures significant events that are
of interest to the business
Sets context for tasks to be
supported by system
Easily documents as a series of steps
or process diagram
Business Objectives
Business Objectives will
Explain why the project is needed
Identify business
improvements/opportunities to be
addressed
Provide the basis for determining the
success of the investment
Clarify the boundaries of the initiative
Define what the business is expected to
deliver
Support Corporate objectives
Examples Reduce cost of operations, Increase
customer satisfaction, expand customer base
Project Objectives
Characteristics of Project Objectives
Define the scope of the project
Summarize the purpose of the project
Identify at a high-level the products of
the project
What the project team is expected to
deliver
Example- Automate services, Develop
the connectivity to send and receive
information
Needs and Features
Needs
Originate from a business stakeholder
and define the initiate problem or
opportunity the project addresses
Features
High-level description of system
behavior
What the product will do
Exclusions, Assumptions, Constraints
Exclusions
Details that the project will not address
Assumptions
True, real or certain
Involves a high degree of risk
Ex- system can be implemented all over the world
Constraints
Applicable Restrictions that will affect the
performance of the project
Should not be tied to cost or schedule unless
these have been agreed as fixed values
Ex. Automate by next June
Scope Creep
Seemingly small and incremental scope
and requirement changes lead to
substantial cost, budget and schedule
overruns.
Points to Remember
Before exploring requirements for a new
project you have to understand the
following:
The business problem or opportunity
Scope of the Project
Stakeholder interests in the project
Constraints on an acceptable solution
Questions ?
Requirements
What is a Requirement ?
Features become Requirements
A requirement is a
necessary attribute,
capability,
characteristic or
a quality factor of a system or product.
Requirements must be unambiguous,
complete, correct, consistent, traceable,
modifiable, understandable, verifiable,
ranked for importance and stability.
Requirements Definitions
Business Requirements:
High level capability required to meet business
need
What needs to be done, not how it is done
Functional Requirements:
An action that the product must be able to take
functional characteristic of end solution
Should not include technical directions on how to
achieve requirement
Should only be derived from business
requirements
Requirements Definitions
Technical Requirements:
Specific attribute or characteristic of end
product and behavior it must exhibit to meet
functional needs
Low level detail typically containing technical
language
Usability Linked
Business
Performance Functional Rules
Requirements
Maintainability
&
Supportability
Security Technical
Availability/ Requirements
Reliability
Scalability
Requirements Management
1. Gathering Requirements- Identify
sources of raw requirements data
2. Analyzing Requirements- Develop and
analyze raw requirements data and Develop
basic models ( Process Maps, Use Cases)
3. Specifying Requirements- Develop
requirements. Develop BRDs
4. Validating Requirements- Review the
Requirements
5. Tracking Requirements- Develop
Traceability Matrix and track changes
1. Gathering Requirements
Gather information about present methods,
procedures, systems, work processes and
data operations to understand needs.
Choosing a technique: Is there a
right/wrong You decide what works
best.
Techniques used:
A. Hard Sources (documentation)
C. Brainstorming
Document Non-functional
requirements
Document business rules
2. Analyzing Requirements
Two sections:
Individual gathering requirements outline: by
utilizing documentation, templates and
Additional requirements
Modeling techniques: process maps, data
elements, business rules and use cases
3. Specifying Requirements
Optional
Software Requirements Specification
Captures the complete software
requirements for the system, or a
portion of the system.
Package containing use cases and
applicable Supplementary
Specifications and other supporting
information.
Data Elements
Pieces of information needed by the business
<Any conditions that apply after the use case has been
executed>
Alternative Flows
Design constraints
Implementation requirements
Interface requirements
Physical requirements.
Traceability Matrix
The traceability matrix is used to
ensure all requirements are met and
to locate affected system
components when there is a
requirements change
Test Cases
A Test case is a set of test inputs, execution
conditions, and expected results developed for
a particular objective, such as to exercise a
particular program path or to verify
compliance with a specific requirement.
Test cases reflect the requirements that are
to be verified.
The requirements you choose to verify will be
a balance between the cost, risk, and
necessity of having the requirement verified.
Questions ?
Assignment - Case
Study 1
End of Session 1
Rational Unified
Process
Iterative Approach
Phases and associated An iteration:
Iterations:
Inception
Iterations focus on management, requirements, and design
activities
Elaboration
Iterations focus on defining, validating, and base lining the
architecture
Construction
Iterations focus on design, implementation, and testing
ex. Fixing Bugs iteration needed including implementation and testing
Transition
Iterations focus on testing and deployment
ex. User feedback iteration needed
Inception: Project Objectives Milestone
(project viable
1. Business or non-viable)
Modeling
2. Requirements
3. Analysis & Design
4. Implementation
5. Test
6. Deploy
Elaboration: Product Architectural
Milestone (architecture
1. Business Modeling is proven)
2. Requirements
3. Analysis & Design
4. Implementation
5. Test
6. Deploy
Construction: Operational Capability
Milestone (all functionality developed)
1. Business Model
2. Requirements
3. Analysis & Design
4. Implementation
5. Test
6. Deploy
Transition: Product Release Milestone
(product released into production)
1. Business Modeling
2. Requirements
3. Analysis & Design
4. Implementation
5. Test
6. Deploy
RUP phases and their milestones
WORKFLOW STEPS FOR AN ITERATION
Process Human Actions Artifacts Produced
Disciplines
Business Step 1: For initial iteration, Target
Modeling ELICIT Business Rules, Organizational
(Business Business Needs, Assessment
Understanding) Business Document, Business
Understanding ; for all Glossary Document,
subsequent x iterations Business Rules
DETAIL Business Rules, Document, Business
Needs, Understanding Use-Case Model,
Step 2: For initial iteration, Business Vision,
IDENTIFY all significant Object Model,
Business Use-Cases, Business
Specifications, Models, Architecture
Rules, Vision, and Document,
Architecture; for all Supplementary
subsequent x iterations Business
DETAIL Business Use- Specification,
Cases, Specifications, Business Glossary
Models, Rules, Vision,
Architecture
Contd..
Process Human Actions Artifacts
Disciplines Produced
Requirements Step 3: For initial iteration, ELICIT Stakeholder
(User/System Requirements (Requests), & Requests
Requirements Rules; for all subsequent x iterations Requirements
Gathering) DETAIL Requirements Management
(Requests), & Rules. Plan,
Step 4: For initial iteration, IDENTIFY Supplementary
all significant Use-Cases and Specification,
classify by risk; for all subsequent x Use-Case
iterations DETAIL Use-Cases (high Specification,
risk Use-cases first), Use-Case Model,
Specifications, Models, Glossary,
Realizations to match all lower-level Software
Analysis Classes and Analysis Requirements
Diagrams and higher-level Business Specification,
Rules, & Requests. Storyboard, Use-
Step 5: PRIORITIZE or Case Package
REPRIORITIZE USE-CASES by Diagrams, User
RISK. Interface
Prototype
Process Human Actions Artifacts Produced*
Disciplines
Analysis & Step 6: For initial iteration, CREATE Communication
Design Collaboration Diagrams, Analysis Classes, Diagrams, Object
(Behavioral & Analysis Packages, Charts, Realizations, Diagrams, Sequence
Structural Definitions, & Analysis Models; for all Diagrams, State
Modeling) subsequent x iterations DETAIL Charts, Activity
Collaboration Diagrams, Analysis Classes, Diagrams, Package
Analysis Packages, Charts, Realizations, Diagrams, Class
Definitions, & Analysis Models to match all Diagrams, Software
lower-level Design Class Diagrams and Architecture
higher-level Use-Case Models. Document,
Step 7: For initial iteration, CREATE Sequence Deployment Model,
Diagrams, Analysis Classes, Analysis Analysis Model,
Packages, Charts, Realizations, Design Model, Proof-
Definitions, & Analysis Models; for all of-Concept
subsequent x iterations DETAIL Sequence Prototype, Use-Case
Diagrams, Classes, Packages, Charts, Realizations, Design
Realizations, Definitions, & Models to Packages,
match all lower-level Design Class Subsystem Design
Diagrams and higher-level Use-Case Models. Packages, Design
Step 8: For initial iteration, CREATE Design Classes, Unit Test
Classes & Class Diagrams; for all Classes, Analysis
subsequent x iterations ns DETAIL Design Classes, Data
Classes & Class Diagrams to match all Models, Data
higher-level Analysis Classes, Diagrams, & Definitions
Models.
Step 9: For initial iteration, CREATE Data
Models; for all subsequent x iterations
Implementatio For initial iteration, CREATE Component Implementation
n Diagrams & Models; for all Model,
(Process subsequent x iterations DETAIL Component
Modeling) Component Diagrams & Models to Diagrams
reflect any changes to Design
Classes, Diagrams, & Models.