Software requirements

Development of the
Software Requirements

Страница  2 www.specialist.ru
Brief about the trainer: Danil Dintsis
 Start-up consultant with successful portfolio
 Ph. D. (twice) in System Analysis and Technical
management (ISCED verified)
 Portfolio manager and IT consultant, and a trainer for
15+ years with the following certifications:
– PgMP®, PMP®
– EXIN accredited trainer for ITIL®, MOF®, Cloud
computing, Operation services and Analysis (OSA®)

Main sources for our training

Module 1
 Introduction

Path from great idea to business. Review:
http://www.slideshare.net/IAMCP_Mentoring/how-to-create-a-business-plan-44673629
Estimate our
project
Attract
Investors
Our idea is
great!
Clouds!

Define: What do we mean by “requirement”
 A condition or capability needed by a customer/user to solve a
problem or achieve an objective.
 A condition or capability that must be met or possessed by a system
or system component to satisfy a contract, standard, specification, or
other formally imposed document.
 A documented representation of a condition or capability as in item 1
or 2.

Project management lifecycle phases

When do we collect requirements
 Initiating phase
 Planning phase
 Executing phase
 Knowledge area: Scope management
 Processes: Planning Scope management, Requirements collection,
Defining Scope, Change management.

Uncertainties
 Product (What?)
 Project (How?)

Requirements could be addressed to:
- a product
- development processes (a project);
- implementation
- support

Uncertainties in Agile approaches

Uncertainties in Waterfall management

A Requirement Lifecycle
1 Elicitation
2 Analysis
3 Specification
4 Validation
5 Management

Module 2
Stakeholder Identification
Collect requirements

Who are the stakeholders

ITIL® BRM vs Product Manager

BRM and IT Service Portfolio

Tools to collect requirements
Laws, bylaws,
procedures
Focus groups,
Charts
Mission and
vision
Brainstorming & Delphi

How to brainstorm?
 Define a problem
 Gather experts
 Collect ideas in a non-critical manner
 Discuss and rank ideas
 Select 3-4 alternatives

Kepner – Trego analysis
Курс OSA ITIL® 2011 Ковалёв А.В. 2013 г.
Define
What is a problem?
Describe
Features
•Which part needs
improvement?
•Why is it a problem?
Location.
• Where is a problem
appears?
Time
When does a
problem appear??
How often?
Scale
Is a problem
important?
How many job
units are involved?
Search for solutions
Identify 2-3 solutions
Test them
Analyze
Five phases of problem analysis:

The “Delphi” method
 Define a problem
 Define experts
 Collect ideas in an anonymous manner
 Discuss and rank ideas (in person or anonymous)
 Select 3-4 alternatives

REVIEW: HTTP://WWW.SLIDESHARE.NET/IAMCP_MENTORING/STAKEHOLDER-
MANAGEMENT-44672689
NAME Position ROLE in a
PROJECT
CONTACTS REQUIREMENTS EXPECTATIONS INFLUENCE ATTITUDE to
a PROJECT
Mr. X CEO Sponsor Decrease
expenditures per
client
Innovation solution
from world known
vendor
Increase brand value
High Devoted to this
project
STAKEHOLDER REGISTER

Stakeholder Communication strategy
 WIIFM – What In It For Me
 SWOT
 “Difficult” managers (as in CompTIA®):
– Micromanager;
– “Deaf”
– “Aggressor”

Stakeholders’ Impact Analysis Matrix
Influence on a project Negative with high
impact. Involve,
Exclude, Overwhelm
Positive with high
impact. Involve
(Sponsor is in this
quadrant)
Administer Involve, Motivate
Readiness to support ->

Example
Stakeholder impact
High
Low
Negative
Stakeholders: often
middle management
Strategy: WIIFM,
communicate in
person
Sponsor, key
stakeholders
Strategy: involve,
include maximum
demands and
expectations
Often: users, low-level
staff.
Strategy: Describe,
educate, ignore
(administrative efforts)
Power users, team
members
Strategy: involve,
delegate
Project support
Negative Positive

DO IT ON A REGULAR BASIS
 Revise stakeholder register
 Revise stakeholder attention and influence
 Revise Stakeholder management plan
 Ask sponsor for a help
 Initiate change

Module 3
Classify and balance requirements

Requirement’s types
 Functional – describe features of a product
 Non-functional – describe constraints, technical, quality parameters
(for example, availability, MTRS)
 Emergent – are requirements, which describe integration facilities,
constraints, which are critical to a whole system, not only for a certain
product.
 Business – describe business needs, assumptions and constraints
 Technical – describe technical features, parameters, assumptions,
and constraints

Assumptions and Constraints
 Assumption is (80/20)
 Constraint is
 Types of constraints:
– Financial
– Technical
– Compliance
– Organizational

USER STORIES
 As a USER ROLE
 I want _________
 In order to (so that) _____

INVEST principle
 Independent
 Negotiable
 Valuable
 Estimable
 Small
 Testable

EPIC user stories
 EPIC is a large user story, which describes multiple features and
benefits
 An EPIC user story should be divided into several small ones
 Example: As a director I want to control my staff

Ambigious words
 All
 Every
 Forever
 Last
 Both
 Other
 Everybody
 Total

User stories risks

Analyze user stories and bring them together

Story board. User/Workflow View

Story board. Screen view

Balancing requirements

Conceptual Design (as in IEEE 1016)
 Conceptual design is a start point of software design at which
the principles are established in:
– Context viewpoint
– Composition viewpoint
– Logical viewpoint
– Dependency viewpoint
– Information viewpoint
– Patterns use viewpoint
– Interface viewpoint
– Structure viewpoint
– Interaction viewpoint

Feasibility analysis
 Choose base platform/methods/vendor
 Choose 2-3 alternative methods/vendors
 Describe product/project scope more precisely

Functional analysis
 The goal of a functional analysis is validating business vs technical
requirements, constraints, integration opportunities.

Tasks in functional analysis
 Which requirements should be implemented?
 Are all of them necessary?
 Can we unite requirements into sub-systems?
 Prioritize requirements

MoSCoW prioritizing tool
 Must
 Should
 Could
 Would/Won’t

Align business and technical requirements
ID Business Requirement Priority Source ID Technical Requirement Priority Source

Module 4
Develop requirements specification document

Waterfall and Agile approaches

Prototyping
 A prototype is an early sample, model, or release of a product built to
test a concept or process or to act as a thing to be replicated or
learned from.
 Software prototyping is the activity of creating prototypes of
software applications, i.e., incomplete versions of the software
program being developed.

Prototypes type:
 Fast or Rapid or Wireframe
 Evolutional
– Iterative development
– SCRUM sprints
 Extreme (for Web development only), three phases:
– Static prototype (HTML)
– Emulation
– Integrated services

Wireframe
 A very simple visual
representation
 Easy to discuss with users
and between team members
 A base ground for ideas

Advantages of prototyping
 Reduced time and costs: Prototyping can improve the quality of
requirements and specifications provided to developers. Because
changes cost exponentially more to implement as they are detected
later in development, the early determination of what the user really
wants can result in faster and less expensive software.
 Improved and increased user involvement: Prototyping requires
user involvement and allows them to see and interact with a prototype
allowing them to provide better and more complete feedback and
specifications.[7] The presence of the prototype being examined by the
user prevents many misunderstandings and miscommunications that
occur when each side believe the other understands what they said.

Advantages of prototyping
 Involve clients and users
 Minimize threats
 Improve user satisfaction
 No waste time in development (lean)

Disadvantages of prototyping
 Insufficient analysis
 User confusion of prototype and finished system
 Developer attachment to prototype
 Excessive development time of the prototype
 Expense of implementing prototyping

Critical overview. Tools
 Iron triangle
 Occam's razor

System and Software specifications
 ISO/IEC 15288 (IEEE Std 15288™-2008), Systems and software
engineering
 Software Requirements Specification (SRS)
 Related documents:
– SPMP –Software project management Plan
– SQAP – Software quality assurance plan
– STD – Software testing documentation
– SCMP – Software configuration management plan
– SVP – Software verification plan

What is Software Requirements Specification
(SRS)
 A software specification (SRS) is a description of a software system to
be developed. It lays out functional and non-functional requirements, and
may include a set of use cases that describe user interactions that the
software must provide.
 SRS establishes the basis for an agreement between customers and
contractors or suppliers.
 SRS permits a rigorous assessment of requirements before design can
begin and reduces later redesign. It should also provide a realistic basis
for estimating product costs, risks, and schedules. Software requirements
specification prevents software projects from failure
 SRS document enlists enough and necessary requirements that are
required for the project development.
 © Wikipedia. (https://en.wikipedia.org/wiki/Software_requirements_specification)

SRS Goals
 Facilitating reviews
 Describing the scope of work
 Providing a reference to software designers
 Providing a framework for testing primary and secondary use cases
 Including features to customer requirements
 Providing a platform for ongoing refinement via incomplete specs or
questions

SRS Structure
 Introduction
– Purpose
– Definitions
– System overview
– References
 Overall description
– Product perspective
• System Interfaces
• User Interfaces
• Hardware interfaces
• Software interfaces
• Communication Interfaces
• Memory Constraints
– Design constraints
• Operations
• Site Adaptation Requirements
– Product functions
– User characteristics
– Constraints, assumptions and dependencies
 Specific requirements
– External interface requirements
– Functional requirements
– Performance requirements
– Logical database requirement
– Software System attributes
• Reliability
• Availability
• Security
• Maintainability
• Portability
– others

Module 6
Risks.
Resume.

What Is a Risk
 Risk is a probable event, which impacts on a project or a product
 In IT projects usually only negative risks (threats), which have
negative impacts.
 Common risks are called Anti-patterns

Common Project Risks (Threats)
for Requirements
 Analysis Paralysis
 Groupthink
 Cart before the horse
 Vendor lock-in
 Over-engineering

Common Individual Risks
 Heroics
 Gold plating
 Silos

Challenges for requirements elicitation
 'Problems of scope'. The boundary of the system is ill-defined or the
customers/users specify unnecessary technical detail that may
confuse, rather than clarify, overall system objectives.
 Problems of understanding. The customers/users are not
completely sure of what is needed, have a poor understanding of the
capabilities and limitations of their computing environment, don’t have
a full understanding of the problem domain, have trouble
communicating needs to the system engineer, omit information that is
believed to be “obvious,” specify requirements that conflict with the
needs of other customers/users, or specify requirements that are
ambiguous or untestable.
 Problems of volatility. The requirements change over time. The rate
of change is sometimes referred to as the level of requirement
volatility

Requirements quality can be improved through
 Visualization. Using tools that promote better understanding of the
desired end-product such as visualization and simulation.
 Consistent language. Using simple, consistent definitions for
requirements described in natural language and use the business
terminology that is prevalent in the enterprise.
 Guidelines. Following organizational guidelines that describe the
collection techniques and the types of requirements to be collected.
These guidelines are then used consistently across projects.
 Consistent use of templates. Producing a consistent set of models and
templates to document the requirements.
 Documenting dependencies. Documenting dependencies and
interrelationships among requirements.
 Analysis of changes. Performing root cause analysis of changes to
requirements and making corrective actions.

Product Backlog
 A Product backlog is a set of requirements (features) to be developed
in a project
 Features include:
– User stories
– Tasks
– Knowledge tasks
– Common risks and bugs

Product Backlog – by Features
Feature 1 Feature 2 … Feature N
Task1 Task3
Task2 Task5
Task 3 Task 6 …..

Product Backlog – by Priority
Must Should Could Would
Task2 Task 3 Task 4 Task 6
Task1 Task 5

 Contact us at:
 dinzis@specialist.ru
 consult@dintsis.org

Software requirements

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Software requirements

Ähnlich wie Software requirements (20)

Mehr von IAMCP MENTORING

Mehr von IAMCP MENTORING (19)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Software requirements

Hinweis der Redaktion