introduction to software engineering dr. basem alkazemi bykazemi@uqu.edu.sa

Introduction to Software Engineering

Dr. Basem Alkazemibykazemi@uqu.edu.sa

http://uqu.edu.sa/bykazemi

Objectives

Describe what is Software Requirements and its main types.

Identify what need to be elicit and the elicitation techniques.

Explore requirement analysis techniques Define the structure of the requirement

document. Introduce some System modeling

techniques.

What is Requirement?

Requirements are the set of things that a customer requires with a number of constraints that must be satisfied on the final system.

It can be represented in high-level abstract statement of a service or a detailed mathematical functional specification.

Requirements may serve as: The basis for a bid for a contract - therefore must be open

to interpretation;

The basis for the contract itself - therefore must be defined in detail;

Examples of Requirements

“Fire Alarm must go off when a movement is detected before 06:00 and after 19:00”

“The system must dial 999 to inform the Police” “Customers should be able to view their

remaining balance” “The system should identify employee by face”

Requirements Engineering

The process of establishing the activities for interpreting customer requirements to build a complete working system.

Include the following processes: Elicitation Analysis and negotiation Specs generation System modeling Validation Management

Why Reqs are non-tech?

User cannot understand technical details Maybe they could after system Launched!

Reduce restrictions on code developers Satisfy requirements using whatever possible techniques

and tools.

Customer may specify details that might confuse more than clarify!

Fast system, large size, easy to use … etc

Requirement might change over time

Characteristics of good Spec. Implementation Free

Omit technical details. Complete

Should include descriptions of all facilities required. Consistent

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

Unambiguous Common vocabularies are used. Ambiguous requirements may be interpreted in different ways by

developers and users Concise and Minimal

No duplication or unnecessary contents. Clear and Understandable Measurable

Example: “Experienced controllers shall be able to use all the system functions after a total of two hours training. After this training, the average number of errors made by experienced users shall not exceed two per day”.

8

Exercise

Are The following statements right or wrong Specs?“Write a Java program to provide a personal telephone

directory. It should implement functions to look up a number and to enter a new telephone number. The program should provide a friendly user interface.”

“ Data should be stored in Magnetic Disk and the system must retrieve data in 1ms”

9

Forms of requirement 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.

10

Types of Requirements

Functional Requirements Non-Functional Requirements Domain Requirements

11

Functional requirements

Describe functionality or system services. Depend on the type of software, expected users

and the type of system or environment where the software is used.

Functional user requirements may be high-level statements of what the system should do but functional system requirements should describe the system services in detail.

12

Non-functional requirements

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 authorizing a particular CASE system, programming language or development method.

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

13

Example of Non-Functional Reqs

The user interface for LIBSYS shall be implemented as simple HTML without frames or Java applets.

The system development process and deliverable documents shall conform to the process and deliverables defined in XYZCo-SP-STAN-95.

The system shall not disclose any personal information about customers apart from their name and reference number to the operators of the system.

14

Elicit Requirements

The activity of eliciting requirements involves the engineer and users talking together, with the former trying to understand the latter by asking questions and writing notes.

15

Elicitation Techniques

Background reading Documents inspection Interviews Questionnaires Brainstorming Ethnography Prototyping Use-cases and scenarios

16

What to Elicit?

Description of problem domain. medical, chemistry, math … etc.

List of Problems. Any client-imposed constraints upon behavior or

structure of the system. The main motivation behind the development.

17

Sources of Information

Client Documentation of Pre-exiting system Users of pre-existing system Possible users of the new system Competitor’s product Domain Expert Relevant standards

18

Guidelines for writing requirements Invent a standard format and use it for all

requirements. Use language in a consistent way. Use shall for

mandatory requirements, should for desirable requirements.

Use text highlighting to identify key parts of the requirement.

Avoid the use of computer terminology.

19

Problems with natural language Lack of clarity

Precision is difficult without making the document difficult to read.

Requirements confusion Functional and non-functional requirements

tend to be mixed-up. Requirements amalgamation

Several different requirements may be expressed together.

20

Requirement Document Structure Preface

Introduction

Objectives

Scope statement

Glossary

User Requirement definition

System Architecture

System Specification

System Models

DFD, STD, SD ..

System Evolution

Appendices

21

Key points

Requirements set out what the system should do and define constraints on its operation and implementation.

Functional requirements set out services the system should provide.

Non-functional requirements constrain the system being developed or the development process.

User requirements are high-level statements of what the system should do. User requirements should be written using natural language, tables and diagrams.