Chapter 3 Project Management

Chapter 4Software Requirements Chapter 6,and 7 in textbook111ObjectivesTo understand the concept of software requirementsTo understand the difference between functional and non functional requirementsUnderstand the importance of getting it right.Understand how requirements are documented (the SRS document) 222OverviewWhat are software requirements?Functional requirementsNon functional requirementsDomain requirementsUser and system requirementsInterface specificationWhy is it important to get it right?The SRS document333What are Software RequirementsThe descriptions of the system services and constraints that are generated during the requirements engineering process.

Developed during the first phase in the software development life cycle.

44The LIBSYS case studyA library system that provides a single interface to a number of databases of articles in different libraries.Users can search for, download and print these articles for personal study.

55Requirements typesFunctional requirementsNon-functional requirementsDomain requirements

66Functional Requirements 7Functional RequirementsDescribe functionality or system services.Depend on the type of software, expected users and the type of system where the software is used.Functional requirements can be User requirements:high-level statements of system functionalitySystem requirements:describe the system services in detail.88User requirements- examplesThe user shall be able to search either all of the initial set of databases or select a subset from it.The user shall be able to order any book by company xyz.99ProblemsProblems arise when requirements are not precisely stated (Ambiguous)

Ambiguous requirements may be interpreted in different ways by developers and users.

1010Non-Functional Requirements11Non-Functional RequirementsThese define system properties, constraints, and process requirements

1212System Properties Reliability,Response time Maintainability Storage requirements.

13Constraints I/O device capability, Data representations used in system interfaces14Process RequirementsMandating a particular CASE system, Programming language or Development method.

15Which do you think is more critical, A functional or non-functional requirement and why?

Have a look at the following video16

Non-functional requirements may be more critical than functional requirements. If these are not met, the system is useless. If an aircraft does not provide its reliability requirement it will not be certified as safe for operation.

16Europeana Project

1717Types of Non-functional requirements

1818ExamplesProduct requirement The user interface for LIBSYS shall be implemented as simple HTML without frames or Java applets.Organisational requirementThe system development process and deliverable documents shall conform to the process and deliverables defined in XYZCo-SP-STAN-95.External requirementThe system shall not disclose any personal information about customers apart from their name and reference number to the operators of the system.

1919Verifiable Non-functional requirementsNon-functional requirements may be very difficult to state precisely Imprecise requirements may be difficult to verify. Therefore we need a statement using some measure that can be objectively tested.

2020Example The system shall be easy to use

Better expressed as:Experienced users 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.21Requirements measures

2222Domain Requirments23Domain Requirements Derived from the application domain and describe system characteristics and features that reflect the domain.Domain requirements may be new functional requirements, constraints on existing requirements or define specific computations.2424ExampleThe deceleration of the train shall be computed as:Dtrain = Dcontrol + Dgradient where Dgradient is 9.81ms2 * compensated gradient/alpha and where the values of 9.81ms2 /alpha are known for different types of train.2525Class ActivityWorking with your team, identify the type of requirements listed on the sheet.When you are done discuss your decisions with the rest of the class.Check each requirement, if you got it right give yourself 1 point.Compute your total. The winning teams will get a smiley sticker26

User and System Requirements27User Requirements Written for customersStatements in natural languageDescribe the services the system provides and its operational constraints.May include diagrams or tablesShould describe functional and non-functional requirements Should be understandable by system users who dont have detailed technical knowledge.We provide a definition for a user requirement.

2828System RequirementsStatements that set out detailed descriptions of the systems functions, services and operational constraints. Defines what should be implemented so may be part of a contract between client and contractor.Intended to be a basis for designing the system.Can be illustrated using system models

We provide a specification for a system requirement.

2929Guidelines 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 jargon.

3030Definition and Specifications

3131Interface Specification Most systems must operate with other systems and the operating interfaces must be specified as part of the requirements.

3232The SRS document33Why is it important to get it right?If you dont do it right you will build a very elegant software solution that solves the wrong problem.

the result is project failure (wasted time, and money, personnel frustration, and customer dissatisfaction.3434Representing Requirements The SRS documentThe Software Requirements Specification (SRS) document is the official statement of what is required of the system developers.

3535The SRS documentShould 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 WHAT the system should do rather than HOW it should do it.

36Users of the SRS

3737Structure of the SRSPrefaceIntroductionGlossaryUser requirements definitionSystem architecture (high level)System requirements specificationSystem modelsSystem evolutionAppendicesIndex

3838Requirments Engineering39Requirements Engineering ProcessThe process of establishing the services that the customer requires from a system and the constraints under which it operates and is developed.

The result is a specification :representing the requirements in a manner that ultimately leads to successful software implementation. 4040Requirements engineering Involves the following processesFeasibility Study Feasibility ReportRequirements elicitation System ModelsRequirements Specification user and system requirementsRequirements validation Requirements document (SRS)+ Requirements Management

4141Requirements Engineering Process

4242The Feasibility StudyA feasibility study decides whether or not the proposed system is worthwhile.A short focused study that checksIf the system contributes to organisational objectives;If the system can be engineered using current technology and within budget;If the system can be integrated with other systems that are used.

4343Requirements ElicitationInvolves technical staff working with customers to find out about the application domain, the services that the system should provide and the systems operational constraints.May involve end-users, managers, engineers involved in maintenance, domain experts, etc. These are called stakeholders.

4444Requirements discoverySources of informationDocumentationSystem stakeholdersInterviewsObservation (ethnography)Specifications of similar systems4545Stakeholders for LIBSYSCan you identify possible stakeholders for the LIBSYS?Library managerArticle providersStudentsStaff4646Analysis : System modelsWhy?The model aids the analyst in understanding the system, thereby makes the requirements analysis easier and more systematic.The model becomes the focal point of review.The model becomes foundation for design.Produced during requirements analysis.More on modeling in chapter 5.4747Requirements specification It is the final work product produced by the requirements engineer.The SRS documentIt serves as a foundation for the software design and implementation. 4848Requirements ValidationThe process of ensuring that the requirements actually define the system that the customer wants.Why is it important? The cost of fixing a requirements problem by making a system change is much greater than repairing design or coding errors. 4949Validation checksValidity checksIs this what the user wants?Consistency checksRequirements should not conflictCompleteness checksRequirements should define all functions and constraintsRealism checksEnsure they could be implemented VerifiabilityRequirements should be written so that they are verifiable, you should be able to write tests for each requirement. 5050Validation techniquesRequirements reviewsA team of reviewers manually check the requirements. PrototypingAn executable model of the system is demonstrated to customers.Test-case generationRequirements should be testable. If tests are difficult or impossible to design, this means that the requirements will be difficult to implement.Developing tests before any code is written is used in ----?5151Requirements Management Why?Requirements for large software systems are always changing. Because the problem can not be fully specified, the requirements are usually incomplete and bound to change.During the software process the stakeholders understanding of the problem is constantly changingAfter the system is installed, new requirements will emerge. What?It is the process of understanding and controlling changes to system requirements. 5252Requirements Management Planning Requirements identificationEach requirement must be uniquely identifiedA change management processAssess the impact and cost of changeTraceability policiesDefine the relationship between requirementsCASE tool support5353Good RequirementsExplanationCharacteristicEverything the software is supposed to do and responses of the software to all classes of input data are specified in the SRSCompleteThe requirement does not contradict any other requirement ConsistentEvery requirement in the SRS represents something required in the final system.CorrectThe requirement is concisely stated without recourse to technical jargon, acronyms (unless defined elsewhere in the Requirements document. Every requirement has one and only one interpretation.UnambiguousThere is a cost effective method that can check whether the final software meets the requirement. Verifiable PropertyMeasure

SpeedProcessed transactions/second

User/Event response time

Screen refresh time

SizeM Bytes

Number of ROM chips

Ease of useTraining time

Number of help frames

ReliabilityMean time to failure

Probability of unavailability

Rate of failure occurrence

Availability

RobustnessTime to restart after failure

Percentage of events causing failure

Probability of data corruption on failure

PortabilityPercentage of target dependent statements

Number of target systems