Requirements and Specification Lecture 03

Prof. Majumdar CS 130 Lecture 3Requirements and SpecificationCS130Lecture 3

Prof. Majumdar CS 130 Lecture 3

AcknowledgementsSlides from Aiken, Sen, Ian SommervilleProf. Majumdar CS 130 Lecture 3


Admin IWe have a second TA: Chuong Nguyen chuong@csIn addition to Tushar Agrawal tushar@cs

PTEs: If you need a PTE, please see me after class todayProf. Majumdar CS 130 Lecture 3


Prof. Majumdar CS 130 Lecture 3Admin III am very impressed by HW1 submissions!I may send out some clarifying questions to some of you

We will put up a short list of projects by WednesdayYou have to bid on projects Please check class website WednesdayWe will make team assignments on WednesdayAnd we start the project !


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

The requirements themselves are the descriptions of the system services and constraints that are generated during the requirements engineering processProf. Majumdar CS 130 Lecture 3


Prof. Majumdar CS 130 Lecture 3Requirements EngineeringThe hardest single part of building a software system is deciding what to buildCripples the process if done wrongCostly to rectify later


QuizThe goal of requirement engineering is to determine (pick one):What software client wants?What software client needs?Prof. Majumdar CS 130 Lecture 3


The LIBSYS systemA 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.Prof. Majumdar CS 130 Lecture 3


Prof. Majumdar CS 130 Lecture 3Determining Stakeholders and NeedsMust determine stakeholdersAnyone who benefits from the system developedE.g., whos client and whos user ?

Try to understand what their needs are

Reconcile different needs/points of view


Prof. Majumdar CS 130 Lecture 3Techniques for Requirement GatheringInterviewing

User stories

Strawmen

Prototypes


Prof. Majumdar CS 130 Lecture 3InterviewingOne path is obviousSit down with client/user and ask questionsListen to what they say, and what they dont say

A less obvious pathMaster-apprentice relationshipHave them teach you what they doGo to workplace and watch them do the task

In all types of interviews, get detailsAsk for copies of reports, logs, emails on processThese may support, fill in, or contradict what the user said


Prof. Majumdar CS 130 Lecture 3Extreme Programming User StoriesRecall: client writes user storiesUsing client vocabulary

Describe usage scenarios of softwareTitle, short description

Each user story has acceptance testsClarify the storyWill tell you when the customer thinks story is done


Prof. Majumdar CS 130 Lecture 3Disadvantages of TalkingInterviews are useful, but I know you believe you understood what you think I said, but I am not sure you realize that what you heard is not what I meant!Users/clients mayNot have the vocabulary to tell you what they needNot know enough about computer science to understand what is possibleOr impossibleSometimes may lead to restricted functionality

Good idea to gather requirements in other ways, too


Prof. Majumdar CS 130 Lecture 3StrawmenSketch the product for the user/clientStoryboardsFlowchartsHTML mock-upsIllustrate major events/interfaces/actions

Anything to convey ideas without writing code!


Prof. Majumdar CS 130 Lecture 3Rapid PrototypingWrite a prototypeMajor functionality, superficially implementedFalls down on moderate-to-extreme examplesNo investment in scaling, error handling, etc.

Show prototype to users/clientsUsers have a real system more reliable feedbackRefine requirementsBut, significant investment


Prof. Majumdar CS 130 Lecture 3Pitfalls of Rapid PrototypingNeeds to be done quicklyRemember, this is just the requirements phase!Danger of spending too long refining prototype

The prototype becomes the productPrototype deliberately not thoroughly thought-outProduct will inherit the sub-optimal architecture

Prototype serves as the specPrototype is incomplete, maybe even contradictory

When done well, extremely useful


Prof. Majumdar CS 130 Lecture 3Summary of Requirements GatheringFind out what users/clients needNot necessarily what they say they want

UseInterviewsUser storiesStrawmenRapid prototyping

As appropriate . . .


Requirement vs SpecificationUser RequirementsStatements in natural language plus diagrams of the services the system provides and its operational constraints. Written for customers.System SpecificationsA structured document setting 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.The distinction is often glossed overProf. Majumdar CS 130 Lecture 3


Prof. Majumdar CS 130 Lecture 3Specifications

Describe the functionality of the productPreciselyCovering all circumstances

Move from the finite to the infiniteFinite examples (requirements) to infinite set of possible computationsThis is not easy


Completeness and consistencyIn principle, specifications should be unambiguous, complete, and consistent.Unambiguous: Only one way to interpret the specCompleteInclude descriptions of all facilities required.ConsistentThere should be no conflicts or contradictions in the descriptions of the system facilities.

In practice, it is impossible to produce a complete and consistent requirements document.Prof. Majumdar CS 130 Lecture 3


Prof. Majumdar CS 130 Lecture 3Different Views of SpecificationsDevelopersSpecification must be detailed enough to be implementableUnambiguousSelf-consistent

Clients/usersSpecifications must be comprehensibleUsually means: not too technical

LegalSpecification can be a contractShould include acceptance criteriaIf the software passes tests X, Y, and Z, it will be accepted


User requirementsShould describe requirements in such a way that they are understandable by system users who dont have detailed technical knowledge.

User requirements are defined using natural language, tables and diagrams as these can be understood by all users.Prof. Majumdar CS 130 Lecture 3


Prof. Majumdar CS 130 Lecture 3Informal SpecificationsWritten in natural language E.g., English

ExampleIf sales for current month are below target sales, then report is to be printed, unless difference between target sales and actual sales is less than half of difference between target sales and actual sales in previous month, or if difference between target sales and actual sales for the current month is under 5%


Prof. Majumdar CS 130 Lecture 3Problems with Informal SpecsInformal specs of any size inevitably suffer from serious problemsOmissionsSomething missingAmbiguitiesSomething open to multiple interpretationsContradictionsSpec says do A and do not do AAmalgamationDifferent requirements mixed together

These problems will be faithfully implemented in the software unless found in the spec


Prof. Majumdar CS 130 Lecture 3Informal Specifications Revisited

If sales for current month are below target sales, then report is to be printed, unless difference between target sales and actual sales is less than half of difference between target sales and actual sales in previous month, or if difference between target sales and actual sales for the current month is under 5%


Prof. Majumdar CS 130 Lecture 3Informal Specifications RevisitedIf sales for current month are below target sales, then report is to be printed, unless difference between target sales and actual sales is less than half of difference between target sales and actual sales in previous month, or if difference between target sales and actual sales for the current month is under 5%

January: target $100K, actual $64KFebruary: target $120K, actual $100KMarch: target $100K, actual $95,100


LIBSYS requirement4..5 LIBSYS shall provide a financial accounting system that maintains records of all payments made by users of the system. System managers may configure this system so that regular users may receive discounted rates.



Requirement problemsDatabase requirements includes both conceptual and detailed information

Describes the concept of a financial accounting system that is to be included in LIBSYS;However, it also includes the detail that managers can configure this system - this is unnecessary at this level.



Prof. Majumdar CS 130 Lecture 3Comments on Informal SpecificationInformal specification is universally reviledBy academicsBy how to authors

Informal specification is also widely practicedWhy?


Prof. Majumdar CS 130 Lecture 3Why Do People Use Informal Specs?The common language is natural languageCustomers cant read formal specsNeither can most programmersOr most managers / lawyersA least-common denominator effect takes hold

Truly formal specs are very time-consumingAnd hard to understandAnd overkill for most projects


Prof. Majumdar CS 130 Lecture 3Semi-Formal SpecsBest current practice is semi-formal specsAllows more precision than natural language where desired

Usually a boxes-and-arrows notationMust pay attention to:What boxes meanWhat arrows meanDifferent in different systems!Well see one example (UML) next time


Functional and non-functionalFunctional requirementsStatements of services the system should provide, how the system should react to particular inputs and how the system should behave in particular situations.Non-functional requirementsconstraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc.Domain requirementsRequirements that come from the application domain of the system and that reflect characteristics of that domain.



Functional requirementsDescribe functionality or system services

Functional user requirements may be high-level statements of what the system should do but functional system specifications should describe the system services in detail.Prof. Majumdar CS 130 Lecture 3


The LIBSYS systemA 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.Prof. Majumdar CS 130 Lecture 3


Examples: functional requirementsThe user shall be able to search either all of the initial set of databases or select a subset from it.The system shall provide appropriate viewers for the user to read documents in the document store. Every order shall be allocated a unique identifier (ORDER_ID) which the user shall be able to copy to the accounts permanent storage area.Prof. Majumdar CS 130 Lecture 3


Example of Requirements imprecisionAmbiguous requirements may be interpreted in different ways by developers and users.

Consider the term appropriate viewersUser intention - special purpose viewer for each different document type;Developer interpretation - Provide a text viewer that shows the contents of the document.Prof. Majumdar CS 130 Lecture 3


Non-functional requirementsThese 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 process, programming language, or development method.Non-functional requirements may be more critical than functional requirements. If these are not met, the system is useless.Prof. Majumdar CS 130 Lecture 3


Non-functional classificationsProduct requirementsRequirements which specify that the delivered product must behave in a particular way e.g. execution speed, reliability, etc.Organizational requirementsRequirements which are a consequence of organisational policies and procedures e.g. process standards used, implementation requirements, etc.External requirementsRequirements which arise from factors which are external to the system and its development process e.g. interoperability requirements, legislative requirements, etc.Prof. Majumdar CS 130 Lecture 3


Non-functional requirement typesProf. Majumdar CS 130 Lecture 3


Non-functional requirements examplesProduct requirement8.1The user interface for LIBSYS shall be implemented as simple HTML without frames or Java applets.Organizational requirement9.3.2 The system development process and deliverable documents shall conform to the process and deliverables defined in XYZCo-SP-STAN-95.External requirement7.6.5 The system shall not disclose any personal information about customers apart from their name and reference number to the operators of the system.Prof. Majumdar CS 130 Lecture 3


Goals and requirementsNon-functional requirements/specifications may be very difficult to state precisely and imprecise requirements may be difficult to verify. GoalA general intention of the user such as ease of use.Verifiable non-functional requirementA statement using some measure that can be objectively tested.Goals are helpful to developers as they convey the intentions of the system users.Prof. Majumdar CS 130 Lecture 3


ExamplesA system goalThe system should be easy to use by experienced controllers and should be organized in such a way that user errors are minimised

A verifiable non-functional requirementExperienced 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.



Requirements interactionConflicts between different non-functional requirements are common in complex systems

Spacecraft systemTo minimise weight, the number of separate chips in the system should be minimised.To minimise power consumption, lower power chips should be used.However, using low power chips may mean that more chips have to be used. Which is the most critical requirement?Prof. Majumdar CS 130 Lecture 3


Domain requirementsDerived from the application domain and describe system characteristics and features that reflect the domain.Domain requirements be new functional requirements, constraints on existing requirements or define specific computations.If domain requirements are not satisfied, the system may be unworkable.Prof. Majumdar CS 130 Lecture 3


Library system domain requirementsThere shall be a standard user interface to all databases which shall be based on the Z39.50 standard.Because of copyright restrictions, some documents must be deleted immediately on arrival. Depending on the users requirements, these documents will either be printed locally on the system server for manually forwarding to the user or routed to a network printer.



Train protection systemThe 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.Prof. Majumdar CS 130 Lecture 3


Domain requirements problemsUnderstandabilityRequirements are expressed in the language of the application domain;This is often not understood by software engineers developing the system.

ImplicitnessDomain specialists understand the area so well that they do not think of making the domain requirements explicit.Prof. Majumdar CS 130 Lecture 3


Guidelines for writing requirementsInvent a standard format and use it for all requirements.Use language in a consistent way. Use shall or must for mandatory requirements, should for desirable requirements

See Reading on the Lectures pageProf. Majumdar CS 130 Lecture 3


System specificationsMore detailed specifications of system functions, services and constraints than user requirements.Intended to be a basis for designing the system.May be incorporated into the system contract.



Requirements and designIn principle, requirements should state what the system should do and the design should describe how it does this

In practice, requirements and design are inseparableA system architecture may be designed to structure the requirements;The system may inter-operate with other systems that generate design requirements;The use of a specific design may be a domain requirement.Prof. Majumdar CS 130 Lecture 3


The requirements documentThe 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 itProf. Majumdar CS 130 Lecture 3


Users of a requirements documentProf. Majumdar CS 130 Lecture 3


IEEE requirements standardDefines a generic structure for a requirements document that must be instantiated for each specific system. Introduction.General description.Specific requirements.Appendices.Index.



Key pointsRequirements set out what the system should do and define constraints on its operation and implementationFunctional 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 doSystem specifications are intended to communicate the functions that the system should provideA software requirements document is an agreed statement of the system requirements.



Safety Critical SystemsA class of systems for which precise (unambiguous, complete, consistent) specifications are necessary

Failures can cause loss of life / property

Requirements fairly stableProf. Majumdar CS 130 Lecture 3


Dependability requirementsFunctional requirements to define error checking and recovery facilities and protection against system failures.Non-functional requirements defining the required reliability and availability of the system.Excluding requirements that define states and conditions that must not arise.Prof. Majumdar CS 130 Lecture 3


Risk-driven specificationSpecification is risk-driven.

Widely used in safety and security-critical systems

The aim of the specification process should be to understand the risks (safety, security, etc.) faced by the system and to define requirements that reduce these risksProf. Majumdar CS 130 Lecture 3


Stages of risk-based analysisRisk identificationIdentify potential risks that may arise.Risk analysis and classificationAssess the seriousness of each risk.Risk decompositionDecompose risks to discover their potential root causes.Risk reduction assessmentDefine how each risk must be taken into eliminated or reduced when the system is designed.Prof. Majumdar CS 130 Lecture 3


Risk-driven specificationProf. Majumdar CS 130 Lecture 3


Risk identificationIdentify the risks faced by the critical system.In safety-critical systems, the risks are the hazards that can lead to accidents.In security-critical systems, the risks are the potential attacks on the system.In risk identification, you should identify risk classes and position risks in these classes Service failure;Electrical risks;Prof. Majumdar CS 130 Lecture 3


Insulin pump risksInsulin overdose (service failure).Insulin underdose (service failure).Power failure due to exhausted battery (electrical).Electrical interference with other medical equipment (electrical).Poor sensor and actuator contact (physical).Parts of machine break off in body (physical).Infection caused by introduction of machine (biological).Allergic reaction to materials or insulin (biological).Prof. Majumdar CS 130 Lecture 3


Risk analysis and classificationThe process is concerned with understanding the likelihood that a risk will arise and the potential consequences if an accident or incident should occur.Risks may be categorised as:Intolerable. Must never arise or result in an accidentAs low as reasonably practical(ALARP). Must minimise the possibility of risk given cost and schedule constraintsAcceptable. The consequences of the risk are acceptable and no extra costs should be incurred to reduce hazard probabilityProf. Majumdar CS 130 Lecture 3


Levels of riskProf. Majumdar CS 130 Lecture 3


Social acceptability of riskThe acceptability of a risk is determined by human, social and political considerations.In most societies, the boundaries between the regions are pushed upwards with time i.e. society is less willing to accept riskFor example, the costs of cleaning up pollution may be less than the costs of preventing it but this may not be socially acceptable.Risk assessment is subjectiveRisks are identified as probable, unlikely, etc. This depends on who is making the assessment.



Risk assessmentEstimate the risk probability and the risk severity.It is not normally possible to do this precisely so relative values are used such as unlikely, rare, very high, etc.The aim must be to exclude risks that are likely to arise or that have high severity.Prof. Majumdar CS 130 Lecture 3


Risk assessment - insulin pumpProf. Majumdar CS 130 Lecture 3


Identified hazard

Hazard probability

Hazard severity

Estimated risk

Acceptability

1. Insulin overdose

Medium

High

High

Intolerable

2. Insulin underdose

Medium

Low

Low

Acceptable

3. Power failure

High

Low

Low

Acceptable

4. Machine incorrectly fitted

High

High

High

Intolerable

5. Machine breaks in patient

Low

High

Medium

ALARP

6. Machine causes infection

Medium

Medium

Medium

ALARP

7. Electrical interference

Low

High

Medium

ALARP

8. Allergic reaction

Low

Low

Low

Acceptable

Risk decompositionConcerned with discovering the root causes of risks in a particular system.

Techniques have been mostly derived from safety-critical systems and can beInductive, bottom-up techniques. Start with a proposed system failure and assess the hazards that could arise from that failure;Deductive, top-down techniques. Start with a hazard and deduce what the causes of this could be.Prof. Majumdar CS 130 Lecture 3


Fault-tree analysisA deductive top-down technique.Put the risk or hazard at the root of the tree and identify the system states that could lead to that hazard.Where appropriate, link these with and or or conditions.A goal should be to minimise the number of single causes of system failure.Prof. Majumdar CS 130 Lecture 3


Insulin pump fault treeProf. Majumdar CS 130 Lecture 3


Risk reduction assessmentThe aim of this process is to identify dependability requirements that specify how the risks should be managed and ensure that accidents/incidents do not arise.Risk reduction strategiesRisk avoidance;Risk detection and removal;Damage limitation.Prof. Majumdar CS 130 Lecture 3


Strategy useNormally, in critical systems, a mix of risk reduction strategies are used.In a chemical plant control system, the system will include sensors to detect and correct excess pressure in the reactor.However, it will also include an independent protection system that opens a relief valve if dangerously high pressure is detected.Prof. Majumdar CS 130 Lecture 3


Insulin pump - software risksArithmetic errorA computation causes the value of a variable to overflow or underflow;Maybe include an exception handler for each type of arithmetic error.Algorithmic errorCompare dose to be delivered with previous dose or safe maximum doses. Reduce dose if too high.Prof. Majumdar CS 130 Lecture 3


Safety requirements - insulin pumpProf. Majumdar CS 130 Lecture 3


SR1: The system shall not deliver a single dose of insulin that is greater than a specified maximum dose for a system user.

SR2: The system shall not deliver a daily cumulative dose of insulin that is greater than a specified maximum for a system user.

SR3: The system shall include a hardware diagnostic facility that shall be executed at least 4 times per hour.

SR4: The system shall include an exception handler for all of the exceptions that are identified in Table 3.

SR5: The audible alarm shall be sounded when any hardware or software anomaly is discovered and a diagnostic message as defined in Table 4 should be displayed.

SR6: In the event of an alarm in the system, insulin delivery shall be suspended until the user has reset the system and cleared the alarm.

Safety specificationThe safety requirements of a system should be separately specified.These requirements should be based on an analysis of the possible hazards and risks as previously discussed.Safety requirements usually apply to the system as a whole rather than to individual sub-systems. In systems engineering terms, the safety of a system is an emergent property.Prof. Majumdar CS 130 Lecture 3


IEC 61508An international standard for safety management that was specifically designed for protection systems - it is not applicable to all safety-critical systems.Incorporates a model of the safety life cycle and covers all aspects of safety management from scope definition to system decommissioning.Prof. Majumdar CS 130 Lecture 3


Safety requirementsFunctional safety requirementsThese define the safety functions of the protection system i.e. the define how the system should provide protection.Safety integrity requirementsThese define the reliability and availability of the protection system. They are based on expected usage and are classified using a safety integrity level from 1 to 4.Prof. Majumdar CS 130 Lecture 3


Security specificationHas some similarities to safety specificationNot possible to specify security requirements quantitatively;The requirements are often shall not rather than shall requirements.Required by regulatory requirements (HIPAA)

DifferencesGeneric threats rather than system specific hazards;Mature security technology (encryption, etc.). However, there are problems in transferring this into general use;The dominance of a single supplier (Microsoft) means that huge numbers of systems may be affected by security failure.Prof. Majumdar CS 130 Lecture 3


Types of security requirementIdentification requirements.Authentication requirements.Authorisation requirements.Immunity requirements.Integrity requirements.Intrusion detection requirements.Non-repudiation requirements.Privacy requirements.Security auditing requirements.System maintenance security requirements.Prof. Majumdar CS 130 Lecture 3


LIBSYS security requirementsProf. Majumdar CS 130 Lecture 3


SEC1:All system users shall be identified using their library card number and personal password.

SEC2:Users privileges shall be assigned according to the class of user (student, staff, library staff).

SEC3:Before execution of any command, LIBSYS shall check that the user has sufficient privileges to access and execute that command.

SEC4:When a user orders a document, the order request shall be logged. The log data maintained shall include the time of order, the users identification and the articles ordered.

SEC5:All system data shall be backed up once per day and backups stored off-site in a secure storage area.

SEC6: Users shall not be permitted to have more than 1 simultaneous login to LIBSYS.

Next TimeSemi-formal specs using UMLProf. Majumdar CS 130 Lecture 3


*****Customers may not know what they need.Even if they know what they need, they may have difficulty in effectively communication these ideas to the developers.

*********Requirements are wishes***Mars Climate Orbiter.Constraints the product:Reliability constraint: life support systemRapid response time: 95% of type 4 requests should be responded within 0.25 seconds.Timing constraint: a war plane should be able detect an incoming missile in 0.25 seconds with 100% probability

Solution strategy:Note down strategies that have been discarded and why*many systems have no detailed specificationgovernment requires detailed spec.business systems: you do not have specs

XP tries to minimize written documentsdocuments for library code used by others available from public websitedocuments are required if you want to be maintained by others.*********

Requirements and Specification Lecture 03

Documents

Transcript of Requirements and Specification Lecture 03