Software Requirements Requirements Engineering, Requirements Analysis

B. Lund. (2013). Lunch. Available: http://www.lunchstriper.no, http://www.dagbladet.no/tegneserie/lunch/

Hans-Petter Halvorsen

Software Requirements

Requirements for a software system set out what the system should do and define constraints on its operation and implementation

Requirements: “The statements that describe what the software system should be but not how it is to be constructed.” Requirements Engineering: “A set of activities related to the development and agreement of the final set of requirement specifications.” Steps in the Requirements Engineering Process:

Software Requirements Requirements Engineering

Requirements Engineering

What is Requirements Engineering? Requirements is the bridge between the real world and the software system Requirements User World

Software System

An Introduction to Requirements Engineering: https://youtu.be/Ec0s0z5uXQ8

Requirements Engineering

What the Customer got What the Customer really needed

Software Requirements & Design Requirements (WHAT): • WHAT the system should do • Describes what the system should do with Words and Figures,etc. • SRS – Software Requirements Specification Document Software Design (HOW): • HOW it should do it • Examples: GUI Design, UML, ER diagram, CAD, etc. • SDD – Software Design Document

Note! Many don't separate SRS and SDD documents, but include everything in a Requirements & Design Document (SRD document). In practice, requirements and design are inseparable.

User Requirements

Customer Requirements System Requirements

B. Lund. (2013). Lunch. Available: http://www.lunchstriper.no, http://www.dagbladet.no/tegneserie/lunch/

Communication between Customers/Stakeholders and Software/IT people is demanding! What does the Customers really want/need? Functional Requirements

Non-Functional Requirements

6 dimensions of Requirements There are six main categories of information that must be addressed in the Requirements specifications:

“Individual functionality” is the the natural starting point. Ask the Users and Customers what their problems are in terms of what functions need to be implemented in the product.

Who will read it?

System customers

Specify the requirements and read them to check that they meet their needs. Customers specify changes to the requirements.

Managers

Use the requirements document to plan a bid for the system and to plan the system development process.

System engineers

Use the requirements to understand what system is to be developed.

System test engineers

Use the requirements to develop validation tests for the system.

System maintenance engineers

Use the requirements to understand the system and the relationships between its parts.

Users of a requirements document

I. Sommerville, Software Engineering: Pearson, 2010.

The Development Process involves different phases

The Development Process The Requirements may be given by the Customer

Requirements

In this case the overall Requirements are given by the Teacher in the Assignment. The details are written by you!

Design The Design phase is important, but make sure you have time left for all the other tasks as well)

Are the Design wrong? Go back and correct it!

When you are finished, you deploy and test the solution on the Customer Site

Implementation Errors? Improve your code and fix the bugs

Testing

Deployment

Make sure everything work as expected

Why spend time on Requirements Analysis?

Cost per defects and changes

Software Development Life Cycle (SDLC)

Software Requirements Hans-Petter Halvorsen

Software Requirements Typical written by the Customers

Typical written by Software Architects, etc.

High-Level Requirements

Detailed Requirements

…

…

….

…

High-Level Requirements vs. Detailed Requirements

High-Level Requirements • • • • • • •

WHAT should the system do? Who should use the system What is the purpose with the system? Performance What parts should the system consists of What Platforms should be used (PC, Tablet, Web?, ...) etc.

Use Words and Figures in order to describe these Requirements

Detailed Requirements and Design • • • • • • • • •

What Platforms should be used (Windows, iOS, ...) in more detail Tools and Languages Software Architecture () Frameworks (.NET, ASP.NET, ...) Detailed GUI design sketches UML Diagrams ER (Database) Diagrams CAD Drawings etc.

Software Requirements Categories

Requirements

User Requirements

System Requirements

Requirements

Functional Requirements

Non-Functional Requirements

Software Requirements Categories Requirements: Statements in natural language plus diagrams of the services the system provides and its operational constraints. Written for customers. User Requirements Statements in natural language plus diagrams of the services the system provides and its operational constraints. Written for customers.

System Requirements

Functional Requirements

Non-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.

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.

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.

User vs. System Requirements 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. I. Sommerville, Software Engineering: Pearson, 2010.

User vs. System Requirements Who will read them? User requirements

Client managers System end-users Client engineers Contractor managers System architects

System requirements

System end-users Client engineers System architects Software developers

I. Sommerville, Software Engineering: Pearson, 2010.

User vs. System Requirements User requirement definition

Examples:

1. The MHC-PMS shall generate monthly management reports showing the cost of drugs prescribed by each clinic during that month. System requirements specification 1.1 On the last working day of each month, a summary of the drugs prescribed, their cost and the prescribing clinics shall be generated. 1.2 The system shall automatically generate the report for printing after 17.30 on the last working day of the month. 1.3 A report shall be created for each clinic and shall list the individual drug names, the total number of prescriptions, the number of doses prescribed and the total cost of the prescribed drugs. 1.4 If drugs are available in different dose units (e.g. 10mg, 20 mg, etc.) separate reports shall be created for each dose unit. 1.5 Access to all cost reports shall be restricted to authorized users listed on a management access control list.

I. Sommerville, Software Engineering: Pearson, 2010.

Functional vs. Non-Functional Requirements 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.

I. Sommerville, Software Engineering: Pearson, 2010.

Functional Requirements • Describe functionality or system services. • Depend on the type of software, expected users and the type of system where the software is used. • Functional user requirements may be high-level statements of what the system should do. • Functional system requirements should describe the system services in detail.

I. Sommerville, Software Engineering: Pearson, 2010.

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. • Process requirements may also be specified mandating a particular IDE, programming language or development method. • Non-functional requirements may be more critical than functional requirements. If these are not met, the system may be useless. I. Sommerville, Software Engineering: Pearson, 2010.

Non-Functional Requirements Examples: Product Requirement: The system shall be available to all clinics during normal working hours (Mon–Fri, 0830–17.30). Downtime within normal working hours shall not exceed five seconds in any one day. Organizational Requirement: Users of the system shall authenticate themselves using their health authority identity card. External requirement: The system shall implement patient privacy provisions as set out in HStan-03-2006priv.

I. Sommerville, Software Engineering: Pearson, 2010.

Exercise - Requirements • Create User and System Requirements for your system • Create Functional and Non-Functional Requirements for your system

Software Design Hans-Petter Halvorsen

System Overview and Architecture • The big picture • Give an introduction to your system and the main pieces, and how they are connected, etc. • MS PowerPoint or Visio are good tools to use

Design

B. Lund. (2013). Lunch. Available: http://www.lunchstriper.no, http://www.dagbladet.no/tegneserie/lunch/

GUI Design and Technical Design (UML, ER diagram, CAD)

GUI Design Sketches “Mockups”

Flow Charts High-Level Flow Charts makes it easy to see how the system shall work The Flow Charts should be understood by non-programmers like the Stakeholders, Project Managers and Customers

Note! Later you may create more detailed diagrams such as UML diagrams, etc.

MS Visio or MS PowerPoint has built in features for creating Flow Charts

Flow Chart Symbols

Interface specifications Module 1

?

? How do different modules interact with each other? What is input and output from the different Modules?

Module 3

Module 2

?

UML Unified Modelling Language

Hans-Petter Halvorsen

Why use UML? • Design – Forward Design: doing UML before coding. Makes it easier to create the code in a structured manner – Backward Design: doing UML after coding as documentation – When doing changes in the Design, make sure to update the Code according to the new Design

• Code – Some Tools can Auto generate Code from UML diagrams – When doing changes in the Code, make sure to update the UML Diagrams

Types of UML Diagrams

http://en.wikipedia.org/wiki/Unified_Modeling_Language

Use Case Diagram

Sequence Diagram

http://en.wikipedia.org/wiki/Sequence_diagram

SRS Document Hans-Petter Halvorsen

Typical Documentation 1. Planning 2.Requierements /Design

Time

Project Management (Gantt Chart, etc.)

Start

(The stakeholders, the software team; architects, UX designers, developers)

2. Testing (QA people)

3. End-user Documentation

(The people that shall actually use Finish the software)

Development Plan

(SDP)

High-Level Requirements and Design Documents Detailed Requirements and Design Documents Test Plans

WHAT HOW

Test Documentation System Documentation Installation Guides User Manuals

(SRS) (SDD)

ER Diagram (Database) UML Diagrams (Code) CAD Drawings, etc. How to Test/ (STP) What to Test (STD) Proof that you have tested and that the software works as expected

Technical Stuff

(Super User/ IT dep.)

How to install it How to use it

(End User)

Project Documentation Documentation produced during a software Project can be divided into 2 Categories: • Process Documentation – These documents record the process of development and maintenance, e.g., Plans (Software Development Plan, Software Test Plan, ...), Schedules (e.g., Gantt Charts), etc.

• Product Documentation – These documents describe the product that is being developed. Can be divided into 2 sub categories: • System Documentation – Used by engineers developing and maintaining the system

• User Documentation – Used by the people that is using the system

Documentation Categories Project Documentation Process Documentation Project Plan, Gant Chart, Meeting Documents, Requirements & Design documentation, Emails, Test documents, other kind of Working Documents, etc. System Documentation

Product Documentation

User Documentation

Installation Guides Technical Documentation needed in User Manual, Wikis, Online order to maintain the software, etc. Help, etc.

The Software Requirements Document Software Requirements Specifications (SRS)

• The software requirements document is the official statement of what is required of the system developers. • 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. I. Sommerville, Software Engineering: Pearson, 2010.

UML Diagrams

Requirements Analysis Written High-Level Requirements

Diagrams as Figures + Descriptions of each

etc.

Use Case Document?

System Sketches, Flow Charts, etc.

SRS/SDD Document(s) Diagrams as Figures + Descriptions of each

Design Sketches -both System Arcitecture and GUI mockups

CAD Drawings

Database Diagram(s)

Diagrams as Figures + Overall Descriptions and descriptions for each table

etc.

Useful when your project involves hardware

The Structure of the SRS Document Chapter

Description

Preface

This should define the expected readership of the document and describe its version history, including a rationale for the creation of a new version and a summary of the changes made in each version.

Introduction

This should describe the need for the system. It should briefly describe the system’s functions and explain how it will work with other systems. It should also describe how the system fits into the overall business or strategic objectives of the organization commissioning the software.

Glossary

This should define the technical terms used in the document. You should not make assumptions about the experience or expertise of the reader.

User requirements definition

Here, you describe the services provided for the user. The nonfunctional system requirements should also be described in this section. This description may use natural language, diagrams, or other notations that are understandable to customers. Product and process standards that must be followed should be specified.

System architecture

This chapter should present a high-level overview of the anticipated system architecture, showing the distribution of functions across system modules. Architectural components that are reused should be highlighted.

System requirements specification

This should describe the functional and nonfunctional requirements in more detail. If necessary, further detail may also be added to the nonfunctional requirements. Interfaces to other systems may be defined.

System models

This might include graphical system models showing the relationships between the system components and the system and its environment. Examples of possible models are object models, data-flow models, or semantic data models.

System evolution

This should describe the fundamental assumptions on which the system is based, and any anticipated changes due to hardware evolution, changing user needs, and so on. This section is useful for system designers as it may help them avoid design decisions that would constrain likely future changes to the system.

Appendices

These should provide detailed, specific information that is related to the application being developed; for example, hardware and database descriptions. Hardware requirements define the minimal and optimal configurations for the system. Database requirements define the logical organization of the data used by the system and the relationships between data.

Index

Several indexes to the document may be included. As well as a normal alphabetic index, there may be an index of diagrams, an index of functions, and so on.

I. Sommerville, Software Engineering: Pearson, 2010.

Users of SRS

System customers

Specify the requirements and read them to check that they meet their needs. Customers specify changes to the requirements.

Managers

Use the requirements document to plan a bid for the system and to plan the system development process.

System engineers

Use the requirements to understand what system is to be developed.

System test engineers

Use the requirements to develop validation tests for the system.

System maintenance engineers I. Sommerville, Software Engineering: Pearson, 2010.

Use the requirements to understand the system and the relationships between its parts.

UML and Use Case Export statistics

Register patient

Medical receptionist

View personal info.

Manager

Generate report

View record Nurse Edit record

Doctor

Setup consultation

Graphical models, supplemented by text annotations, are used to define the functional requirements for the system; UML use case and sequence diagrams are commonly used. We will learn more about this later!

Exercise – SRS • Create a SRS document for your system.

Requirements in TFS/VSTS Product Backlog & Sprint Backlog

Hans-Petter Halvorsen

What is TFS/VSTS? • Team Foundation server/Visual Studio Team Services (VSTS) is an Application Lifecycle Management (ALM) system, – i.e., the system takes care of all aspects in software development – from planning, requirements, coding, testing, deployment and maintenance. – Agile and Scrum workflow are included

• TFS is a Source Code Control (SCC), Bug Tracking, Project Management, and Team Collaboration platform • Tightly integrated with Visual Studio as Microsoft is the vendor of both Visual Studio and VSTS • Cloud based edition (Hosting Service): “Visual Studio Team Services” (VSTS)

Visual Studio Team Services (VSTS) • We will use Visual Studio Team Services (VSTS) as our software collaboration platform for our software lifecycle management (SDLC). • Here we will add Requirements and Design documents, add Tasks, Source Code, report Bugs, etc. • VSTS is located here: http://www.visualstudio.com

Team Foundation Server (TFS) vs. Visual Studio Team Services (VSTS) Visual Studio Visual Studio don't care if you use TFS or VSTS. You just hook it up using an URL. Team Foundation Server (TFS)

vs.

“Team Foundation Server” (TFS). This is software you can install on a server in your own network. You and your team can then hook up Visual Studio to that server and use TFS. You have to buy the software, buy licenses for users and use your own server.

Visual Studio Team Services (VSTS) “Visual Studio Team Services” (VSTS) is an online version of TFS – hosted by Microsoft. You don't need to install anything, you just pay a monthly fee (until 5 users is for free). VSTS is available from http://www.visualstudio.com

https://en.wikipedia.org/wiki/Team_Foundation_Server

Using TFS/VSTS to create the Backlog

http://msdn.microsoft.com/en-us/library/ee518933.aspx

Sprint Backlog in TFS/VSTS

Break items down into Tasks In the sprint backlog, add a task:

Give the task a name, and estimate the work it will take:

Final Results:

Use the Taskbord to update Tasks The task board is at the heart of daily standups. Move tasks on the task board to reflect their current state.

Use the Taskbord to update Tasks You can assign a task to a specific person:

Use the Taskbord to update Tasks Update the remaining work by either using the drop-down list or typing a specific value:

Burndown Chart Review overall progress by opening the burndown chart for the sprint:

O. Widder. (2013). geek&poke. Available: http://geek-and-poke.com

Typical Challenges • Stakeholders don’t know what they really want. • Stakeholders express requirements in their own terms. • Different stakeholders may have conflicting requirements. • Organisational and political factors may influence the system requirements. • The requirements change during the analysis process. New stakeholders may emerge and the business environment may change. I. Sommerville, Software Engineering: Pearson, 2010.

References • I. Sommerville, Software Engineering: Pearson, 2010. • E. J. Braude and M. E.Bernstein, Software Engineering. Modern Approaches, 2 ed.: Wiley, 2011. • F. Tsui, O. Karam, and B. Bernal, Essentials of Software Engineering, 3 ed.: Jones & Barlett Learning, 2014. • Wikipedia. (2013). Software Development Process. Available: http://en.wikipedia.org/wiki/Software_process • NTNU. (2013). TDT4140 Systemutvikling. Available: http://www.ntnu.no/studier/emner/TDT4140 • UiO. (2013). INF1050 - Systemutvikling. Available: http://www.uio.no/studier/emner/matnat/ifi/INF1050/ • O. Widder. (2013). geek&poke. Available: http://geek-and-poke.com • B. Lund. (2013). Lunch. Available: http://www.lunchstriper.no, http://www.dagbladet.no/tegneserie/lunch/ • S. Adams. Dilbert. Available: http://dilbert.com

Hans-Petter Halvorsen, M.Sc. University College of Southeast Norway www.usn.no E-mail: [email protected] Blog: http://home.hit.no/~hansha/