Software Requirements Engineering Session: 1 Topics: Chapters 1 – 3

Agenda Course Introduction – Review Syllabus What Are Requirements – Chapter 1 The Requirements Process – Chapter 2 Project Blastoff – Chapter 3 Volere Requirements Spec

CHAPTER 1 What Are Requirements?

A Requirement is … A requirement is something that the product must do or a quality that the product must have. A requirement exists either because ◦ 1) the type of product demands certain function or qualities, or ◦ 2) the client wants that requirement to be part of the delivered product.

Why Requirements? They must be specified before attempting to construct the product. How can you design or build the correct product without having requirements? Reports showed the 60% of the errors exist at design time. The cost of good requirements gathering is minor compared to the cost of poor requirements.

Types of Requirements Functional Requirements Functional Requirements ◦ Are things the product must do.  What the new product must do? Non-functional Requirements Non-functional Requirements ◦ Are qualities the product must have.  What qualities must the product have?  Does it have to be fast?  Or easy to use?  Secure from hacking? Constraints Constraints ◦ Are global issues that shape the requirements ◦ For example : use some existing hardware, software or business practice, or it might have to fit within a defined budget or be ready by a defined date..

Testing requirements You start testing as soon as you start to specify the requirements. You first test is to determine if you can quantify the requirement by specifying its fit criterion. This Fit Criterion is an objective measure of the requirement’s for evaluating whether or not a given solution fits the requirement.

Requirements & Systems Analysis Process

Requirements Specification Template - Volere Volere is the result of many years of practice, consulting and research in requirements engineering. the form of a generic requirements process, requirements template. Product Constraints Product Constraints 1.The Purpose of the Product 1.The Purpose of the Product – the reason for building 2.The Client, Customer and Other Stakeholders 2.The Client, Customer and Other Stakeholders – have an interest in the product 3.User of the Product 3.User of the Product – intended end-users 4.Requirements Constraints – limitations/restrictions on project

Requirements Specification Template - Volere Functional Requirements Functional Requirements ◦ The Scope of the Product ◦ The Scope of the Product – product boundaries ◦ Functional and Data Requirements ◦ Functional and Data Requirements – things product must do and data manipulated by the functions Non-functional Requirements Non-functional Requirements ◦ Look & Feel ◦ Look & Feel – intended appearance ◦ Usability ◦ Usability – based on intended users ◦ Performance ◦ Performance – how fast, big, accurate, safe, reliable ◦ Operational ◦ Operational – intended operating environment ◦ Maintainability & Portability ◦ Maintainability & Portability – how changeable ◦ Security ◦ Security – security, confidentiality, integrity ◦ Cultural & Political ◦ Cultural & Political – human factors

Requirements Specification Template - Volere Project Issues Project Issues ◦ Off-the-Shelf Solutions ◦ Off-the-Shelf Solutions – products that could be used ◦ Tasks ◦ Tasks – things to be done to bring product into production ◦ Risks ◦ Risks – risks project will most likely face ◦ Costs ◦ Costs – early estimated of the cost or effort needed ◦ User Documentation ◦ User Documentation – plan for building user instructions

Requirements Naming Requirement Numbering ◦ Give each requirement a unique identifier to make it traceable throughout the development process. The numbering scheme suggested in the requirement shell is: ◦ Requirement # is the next unique requirement number ◦ Requirement Type is the section number from the template for this type of requirement For example: A functional requirement is section 9, and the next unique number is 128. Requirement #: 128Requirement Type: 9

Requirements Shell

CHAPTER 2 The Requirements Process

The Requirements Process Project Blastoff Trawling for Requirements Prototyping the requirements Writing the Requirements The Quality Gateway Reusing Requirements Reviewing the Specification

Volere Requirements Process

Project Blastoff Blastoff meeting – to determine key stakeholders, scope of work, product’s purpose, preliminary cost estimates, agreement on go/no-go Major stakeholders invited: ◦ Client ◦ Main users ◦ Lead developers ◦ Technical & business experts ◦ Other people key to success of the project

Trawling For Knowledge

Writing the Requirements

Quality Gateway Testing each requirement for: ◦ Completeness ◦ Correctness ◦ Measurability ◦ Absence of ambiguity ◦ Other qualities

Reusing Requirements

Quiz 1 Q1) Discuss briefly the main phases of the requirement process. Q2)Discuss briefly the main outcomes of the Project Blastoff phase.