COMSCI 3100 LEC (Software Engineering) 2nd Term

Scrum, Requirements Engineering, and UML Modeling.

Scrum

Simple iterative, incremental skeleton with some rules

Scrum

A collaborative effort involving developers and customers in ongoing dialogue

Scrum

A framework with multiple feedback loops and continuous inspection and adaption

Scrum

founded on empirical process control theory, or empiricism.

Transparency

Significant aspects of the process must be visible to those responsible for the outcome. ___________ requires those aspects be defined by a common standard so observers share a common understanding of what is being seen.

Inspection

Scrum users must frequently inspect Scrum artifacts and progress toward a Sprint Goal to detect undesirable variances.

Adaptation

If an inspector determines that one or more aspects of a process deviate outside acceptable limits, and that the resulting product will be unacceptable, the process or the material being processed must be adjusted.

Commitment

Courage

Focus

Openness

Respect

Scrum Values

Product Owner

Defines the features of the product, decides on release date and content

Is responsible for the profitability of the product (ROI)

Prioritizes features according to market value

Can change features and priority very Sprint

Accepts or rejects work results

Scrum Master

Helps resolve impediments

Ensure that the team is fully functional and productive Enables close cooperation across all roles and functions and removes barriers

Shield the team from external interferences

Ensures that the process is followed. Invites to daily scrum, iteration review.

The Development Team

Cross-functional, seven +/- two members

Selects the iteration goal and specifies work results

Has the right to do everything within the boundaries of the project guidelines to reach the iteration goal

Organizes itself and its work

Demos work results to the Product Owner

Sprint Planning

Daily Standup (Daily Scrum)

Sprint Review

Sprint Retrospective

Key Meetings

Sprint Planning

The Product Owner and Team agree on the subset of the Product Backlog to work on this sprint. Result is the Sprint Backlog.

Daily Standup (Daily Scrum)

The Team understands its status every day in order to do a daily “inspect and adapt” cycle.

Sprint Review

The Team shows its Product to the Product Owner and other Stakeholders. The purpose is to “show off” and get buy off and feedback.

Sprint Retrospective

The Team (or Scrum Team) analyzes their own process and modifies it as

Product Backlog

Sprint Backlog

Product

Key Artifacts

Product Backlog

Collection of “stuff” to be done

Features, Capabilities, Issues, etc., often ill-defined

Anyone may add to the Product Backlog

Prioritized by the Product Owner

Sprint Backlog

Work the team has signed up to do

“Well-understood” Stories and Tasks

Product

Running, integrated, tested code

Documentation

Etc.

Sprint Burndown Chart

Shows progress within a Sprint, indicates to the team if it will finish the Sprint Backlog.

Product Backlog

The list for work that is prioritized by the Product Owner

True

True or False:

User Stories are not complete without Acceptance Tests

I – Independent (of all others)

N – Negotiable (not a specific contract for features)

V – Valuable

E – Estimable (to a good estimation)

S – Small (so as to fit within an iteration)

T – Testable (in principle even when there isn’t a test for it yet)

What makes a Good User Story:

Retrospective

Factual

• What went well

• What didn’t go well

• What needs to be improved

Requirements engineering

The process of establishing the services that the customer requires from a system and the constraints under which it operates and is developed.

What is a requirement?

It may range from a high-level abstract statement of a service or of a system constraint to a detailed mathematical functional specification.

User requirements

Statements in natural language plus diagrams of the services the system provides and its operational constraints. Written for customers.

System requirements

A structured document setting out detailed descriptions of the system’s functions, services and operational constraints. Defines what should be implemented so may be part of a contract between client and contractor.

Functional requirements

Statements of services the system should provide, how the system should react to particular inputs and how the system should behave in particular situations.

May state what the system should not do.

Non-functional requirements

Constraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc.

Often apply to the system as a whole rather than individual features or services.

Functional requirements

Describe functionality or system services.

Requirements completeness and consistency

In principle, requirements should be both complete and consistent.

Complete

They should include descriptions of all facilities required.

Consistent

There should be no conflicts or contradictions in the descriptions of the system facilities.

Non-functional requirements

These define system properties and constraints e.g. reliability, response time and storage requirements. Constraints are I/O device capability, system representations, etc.

may be more critical than functional requirements. If these are not met, the system may be useless.

may affect the overall architecture of a system rather than the individual components.

Product requirements

Requirements which specify that the delivered product must behave in a particular way e.g. execution speed, reliability, etc.

Organisational requirements

Requirements which are a consequence of organizational policies and procedures e.g. process standards used, implementation requirements, etc.

External requirements

Requirements which arise from factors which are external to the system and its development process e.g. interoperability requirements, legislative requirements, etc.

Goal

A general intention of the user such as ease of use.

Verifiable non-functional requirement

A statement using some measure that Usability requirements.

Usability requirements

The system should be easy to use by medical staff and should be organized in such a way that user errors are minimized.

SpeedMbytes

Number of ROM chips

Processed transactions/second

User/event response time

Screen refresh time

Size

Mbytes

Number of ROM chips

Ease of use

Training time

Number of help frames

Reliability

Mean time to failure

Probability of unavailability

Rate of failure occurrence

Availability

Robustness

Time to restart after failure

Percentage of events causing failure

Probability of data corruption on failure

Portability

Percentage of target dependent statements

Number of target systems

The software requirements document

the official statement of what is required of the system developers.

It should include both a definition of user requirements and a specification of the system requirements.

It is NOT a design document. As far as possible, it should set of WHAT the system should do rather than HOW it should do it.

Requirements specification

The process of writing on the user and system requirements in a requirements document.

are more detailed requirements and may include more technical information.

Natural language specification

Requirements are written as natural language sentences supplemented by diagrams and tables.

Used for writing requirements because it is expressive, intuitive and universal. This means that the requirements can be understood by users and customers.

Structured specifications

An approach to writing requirements where the freedom of the requirements writer is limited and requirements are written in a standard way.

Requirements elicitation and analysis

Sometimes called requirements elicitation or requirements discovery.

Involves technical staff working with customers to find out about the application domain, the services that the system should provide and the system’s operational constraints.

Stakeholders don’t know what they really want.

Problems of requirements analysis

Requirements discovery

The process of gathering information about the required and existing systems and distilling the user and system requirements from this information.

Scenarios

are real-life examples of how a system can be used.

Use cases

are a scenario based technique in the UML which identify the actors in an interaction and which describe the interaction itself.

A set of use cases should describe all possible interactions with the system.

High-level graphical model supplemented by more detailed tabular description.

Requirements validation

Concerned with demonstrating that the requirements define the system that the customer really wants.

Validity

Does the system provide the functions which best support the customer’s needs?

Consistency

Are there any requirements conflicts?

Completeness.

Are all functions required by the customer included?

Realism.

Can the requirements be implemented given available budget and technology

Verifiability.

Can the requirements be checked?

Requirements reviews

Systematic manual analysis of the requirements.

Prototyping

Using an executable model of the system to check requirements.

Test-case generation

Developing tests for requirements to check testability.

Verifiability

Is the requirement realistically testable?

Comprehensibility

Is the requirement properly understood?

Traceability

Is the origin of the requirement clearly stated?

Adaptability

Can the requirement be changed without a large impact on other requirements?