Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

Software Requirements Engineering

Fundamental concepts of software requirements to be applied primarily at understanding of Software Requirements Engineering process.
by

Mykola Kotliarenko

on 19 August 2016

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Software Requirements Engineering

Business Analysis
Business Analyst
Types of requirements
Schedule
Session 1 - 70 minutes
Break 1 – 10 minutes
Session 2 - 70 minutes
Break 2 – 10 minutes
Session 3 - 70 minutes
Q&A session – 10 minutes
Total – 4 hours
Software Requirements Engineering
Contents at a glance
Mykola Kotliarenko
Business Analyst
on the position,
by education and
by devotion
SDLC
V-model
Iconix
Six Sigma
Waterfall
Spiral model
Agile Development
Artifacts
We had two Software Requirements Specifications, seventy-five Change Requests, five sheets of Backlog, Vision and Scope document, Requirements Management Plan, Business Analysis Communication Plan, Software Architecture Document, and Business Analysis Plan. I was worried about only the last one, BA Plan.
Not that we needed all that for the project, but once you get locked into a serious documents package, the tendency is to push it as far as you can.
Context diagram
Business Process Model
State diagram
Use Case Diagram
Activity diagram
Diagrams
Sequence diagram
RUP
1992 - 2005
1999 - 2013
2009 - 2015
RUP + UML
Ivar Jacobson
“Object-Oriented Software Engineering: A Use Case Driven Approach”, 1992
Ivar Jacobson, Grady Booch, James Rumbaugh “The Unified Software Development Process.”, 1999
Grady Booch, James Rumbaugh, Ivar Jacobson
“Unified Modeling Language User Guide, The, 2nd Edition”, 2005
User-Centered Design, Use Cases, Wiegers
Constantine, L., Lockwood, L.
“Design for Use”, 1999.
Alistair Cockburn
“Writing Effective Use Cases”, 2000.
Karl Wiegers
“Software Requirements”,
1999,
2003,
2013
BABOK
Strategy (Enterprise) Analysis
Solution Evaluation
Why correctly working functionality is not accepted?
Business Analysis Planning
and monitoring
What type of SDLC?
Requirements Life cycle MGMT (mgmt and communication)
Elicitation and collaboration
User Story vs. Use Case
Business analysis: The practice of enabling change in the context of an enterprise by defining needs and recommending solutions that deliver value to stakeholders.
Any person who performs business analysis, no matter their job title or organizational role
History
Why do you follow me?
Levels of Use cases
Very High Summary

Cloud
Flying Kite
Summary
User Goal
Sea
Subfunction
Fish
Too low
Clam
Merge
companies
Merge mortgage
systems
Place
order
Select
product
Insert
orderline
Use Cases Flows
Practice
Use Case template
Goals
Understand:
BA role on the project
main SDLC concepts
main BA techniques
main types of documents
main types of diagrams
Use Case technique
Practice
Literature
What do
stakeholders
need?
Why are we
doing this?
What must the
solution do?
What does BA need to do?
Does it do what it
was supposed to?
Does everyone
understand and agree?
Who can do
this effectively?
Cost
of mistake
Value of business analysis
Projects Success Figures*
53% projects exceed planned budget by 189%

55% projects do not meet business goals

This costs American Business about $30B per year

Focusing on Requirements Saves Budget*
Focusing on Requirements is Key to Success*
*Forrester Research for the US market

*Standish Group CHAOS Report, 2011
* IAG Consulting, 2008
67 %
33 %
20 %
80 %
Fixing requirements errors eats up to 33% of your project budget
>80% of errors are introduced at the requirements analysis stage
Elicitation
Techniques
overview
Interview
The interview is a common technique for eliciting requirements. It involves direct communication with individuals or groups of people who are part of an initiative.
Observation
Observation of activities, also known as job shadowing, involves examining a work activity firsthand as it is performed. It can be conducted in either natural work environments or specially constructed laboratory conditions. The objectives of the observation dictate how it is planned for and methodically conducted.
Brainstorming
Brainstorming is an excellent way to foster creative thinking about a problem. The aim of brainstorming is to produce numerous new ideas, and to derive from them themes for further analysis.
Workshops
A workshop is a focused event attended by key stakeholders and subject matter experts (SMEs) for a concentrated period of time. A workshop may be held for different purposes including planning, analysis, design, scoping, requirements elicitation, modeling, or any combination of these. A workshop may be used to generate ideas for new features or products, to reach consensus on a topic, or to review requirements or designs.
Prototyping
Prototyping is used to elicit and validate stakeholder needs through an iterative process that creates a model or design of requirements. It is also used to optimize user experience, to evaluate design options, and as a basis for development of the final business solution.
Why do you have altered your functionality again and again?
Application
Component
Developer
perspective view
QA
perspective view
System
Architect
perspective view
Business
Analyst
perspective view
Project
Project
Manager
perspective view
Solution
Requirements Analysis
Quality criteria
Atomic
Complete
Consistent
Concise
Feasible
Unambiguous
Testable
Prioritized
Understandable
User Story Quality Checklist
All necessary user story sections are ready
Description
Assumptions and Constraints (
where applicable
)
Acceptance Criteria
Notes (
where applicable
)
Data Discovery details in Notes (
where applicable
)
UI mock-ups attached (
where applicable
)
Supporting files attached (
where applicable
)
*corresponds to the US quality: Independent, Negotiable, Valuable, Estimatable, Sized appropriately or Small = INVEST

Library
Now
Now
Courses
Now
Requirements
Process management
and evaluation
Project management
BI
NFR
Business Analysis
best practices
UI/UX design
Architecture
Templates
Service
Management
Self development
Business Models
Now
Test Cases from Use Cases
Q&A
UML or not?
Prototyping
User-Centered Design
Requirements
Management by Automation
Level of details
Gestalt principles:
Closure
Proximity
Continuation
Similarity
Figure and Ground
The deadline is instant.
Change request... scope creep
• More than 9 years’ experience

• Domains: CRM, MRP (warehouse), SCM (logistics/distribution), ERP (manufacturing, FMCG), BI, OSS/BSS (telecom billing)

• Knowledge in\frameworks\tools: COBIT, BABOK, PMBOK, ITIL practices, ITSM, CMMI, SDLC methodologies, UML, CASE tools

• BA and MA’s degrees with honors in Management of Information Systems

• Certified Business Analyst (CCBA®, CSPO®)
Entity-relationship diagram
Full transcript