Beatrice Åkerblom beatrice@dsv.su.se Everything else in software development depends on the requirements. If you cannot get stable requirements you cannot get a predictable plan... What Is a Requirement?! May range from a high-level abstract statement of a service or of a system constraint to a detailed mathematical functional specification.! This is inevitable as requirements may serve a dual function ~ May be the basis for a bid for a contract -- therefore must be open to interpretation ~ May be the basis for the contract itself -- therefore must be defined in detail ~ Both these statements may be called requirements. Types 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. 3 4
Readers Functional and Nonfunctional User requirements System requirements Software design requirements Client-managers System end-users Client engineers Contractor managers System architects System end-users Client engineers System architects Software developers Client engineers (perhaps) System architects Software developers! 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.! Non-functional requirements ~ Constraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc.! Domain requirements ~ that come from the application domain of the system and that reflect characteristics of that domain. 5 6 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 but functional system requirements should describe the system services in detail Imprecision! Problems arise when requirements are not precisely stated! Ambiguous requirements may be interpreted in different ways by developers and users! Consider the term appropriate viewers ~ User intention -- special purpose viewer for each different document type ~ Developer interpretation -- Provide a text viewer that shows the contents of the document. 7 8
Completeness and Consistency! In principle, requirements should be both complete and consistent.! Complete ~ They should include descriptions of all facilities required.! Consistent ~ There 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. Non-functional! 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 programming language or development method! Non-functional requirements may be more critical than functional requirements. If these are not met, the system is useless 9 10 Goals and! Non-functional requirements may be very difficult to state precisely and imprecise requirements may be difficult to verify! Goal ~ A general intention of the user such as ease of use! Verifiable non-functional requirement ~ A statement using some measure that can be objectively tested! Goals are helpful to developers as they convey the intentions of the system users Examples -- Goals vs. Non-functional! A system goal ~ The system should be easy to use by experienced controllers and should be organised in such a way that user errors are minimised.! A verifiable non-functional requirement ~ 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. 11 12
Property Speed Size Ease of use Reliability Robustness Portability Measures Measure Processed transactions/second User/Event response time Screen refresh time M Bytes Number of ROM chips Training time Number of help frames Mean time to failure Probability of unavailability Rate of failure occurrence Time to restart after failure Percentage of events causing failure Probability of data corruption on failure Percentage of target dependent statements Analysis Techniques! Interviewing (primary technique) ~ Structured or unstructured interviews ~ Questionnaires ~ Forms analysis ~ Video cameras ~ Scenarios! Story boards! Trees! Rapid prototyping 13 14 Rapid Prototyping as Specification Technique! Specifications: Rapid prototype plus list of additional features! Advantages ~ Speed ~ No ambiguities, omissions, contradictions! Disadvantages ~ Specification document is contract ~ Testing requires specifications ~ Maintenance requires specifications! Conclusion: Do not use rapid prototype as specifications Human Factors! Client and intended users must interact with the user interface! Human-computer interface (HCI) ~ Menu, not command line ~ Point and click ~ Windows, icons, pull-down menus! Human factors must be taken into account ~ Lengthy sequence of menus ~ Expertise level of interface ~ Uniformity of appearance ~ Advanced psychology vs. common sense?! Rapid prototype of HCI obligatory 15 16
Problems With! The requirements don!t reflect the real needs of the customer for the system! are inconsistent and/or incomplete! It!s expensive to make changes to requirements after they have been agreed! Misconceptions between the customers, those who develop the requirements and the software engineers developing or maintaining the system Challenges of the Phase! Employees of the client organisation feel threatened by computerisation! team members must be able to negotiate! The client's needs may have to be scaled down! Key employees of the client organisation may not have the time for essential indepth discussions! Flexibility and objectivity are essential 17 18 Guidelines For Writing! 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 Documentation -- Specification In the specification we describe the system that is going to be built 19
Specification Phase! Specification documents should be ~ Informal enough for client ~ Formal enough for developers ~ Free of omissions, contradictions, ambiguities! Specification documents contains the constraints for the product ~ Cost ~ Time ~ Parallel running ~ Portability ~ Reliability ~ Rapid response time Specification Phase (cont!d)! Specification document contains acceptance criteria for the system ~ Vital to spell out series of tests ~ Product passes tests, deemed to satisfy specifications ~ Some are restatements of constraints 21 22 Problems With Natural Language! Lack of clarity ~ Precision is difficult without making the document difficult to read.! confusion ~ Functional and non-functional requirements tend to be mixed-up.! amalgamation ~ Several different requirements may be expressed together. Solution Strategy! General approach to building the product! Find strategies without worrying about constraints! Modify strategies in the light of constraints, if necessary! Keep a written record of all discarded strategies, and why they were discarded ~ To protect the specification team ~ To prevent unwise new solutions during the maintenance phase 23 24
Alternatives to NL Specification! Structured natural language ~ This approach depends on defining standard forms or templates to express the requirements specification.! Design description languages ~ This approach uses a language like a programming language but with more abstract features to specify the requirements by defining an operational model of the system. ~ This approach is not now widely used although it can be useful for interface specifications. Alternatives to NL Specification (cont!d)! Graphical notations ~ A graphical language, supplemented by text annotations is used to define the functional requirements for the system. An early example of such a graphical language was SADT. Now, use-case descriptions and sequence diagrams are commonly used 25 26 Alternatives to NL Specification (cont!d)! Mathematical specifications ~ These are notations based on mathematical concepts such as finitestate machines orsets. These unambiguous specifications reduce the arguments between customer and contractor about system functionality. However, most customers don!t understand formal specifications and are reluctant to accept it as a system contract. Specification Phase! Specification documents should be ~ Informal enough for client ~ Formal enough for developers ~ Free of omissions, contradictions, ambiguities 27 34 28
What happens if the requirements are wrong?! The system may be delivered late and cost more than originally expected.! The customer and end-users are not satisfied with the system.! They may not use its facilities or may even decide to scrap it altogether.! The system may be unreliable in use with regular system errors and crashes disrupting normal operation.! If the system continues in use, the costs of maintaining and evolving the system are very high. Why is requirements engineering difficult?! Businesses operate in a rapidly changing environment so their requirements for system support are constantly changing.! Multiple stake-holders with different goals and priorities are involved in the requirements engineering process.! System stake-holders do not have clear ideas about the system support that they need.! are often influenced by political and organisational factors that stake-holders will not admit to publicly. 29 30 The Engineering Process RE Process Inputs and Outputs Feasibility study Feasibility report elicitation and analysis specification validation System models User and system requirements document ~ Feasability study ~ elicitation & analysis ~ specification ~ validation 31 32
change Feasibility Studies! System requirements reflect the world outside of the system. As this is constantly changing then the requirements will inevitably also change ~ Technology changes ~ Organisational changes ~ Market changes ~ Economic changes ~ Political and legal changes! It is often difficult to understand the implications of changes for the requirements as a whole! A feasibility study decides whether or not the proposed system is worthwhile.! A short focused study that checks ~ If 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. 33 34 Feasibility Study Implementation! Based on information assessment (what is required), information collection and report writing.! Questions for people in the organisation ~ What if the system wasn!t implemented? ~ What are current process problems? ~ How will the proposed system help? ~ What will be the integration problems? ~ Is new technology needed? What skills? ~ What facilities must be supported by the proposed system? Elicitation and Analysis! Sometimes called requirements elicitation or requirements discovery.! Involves technical staff working with customers to find out about the application domain, the services that the system should provide and the system!s operational constraints.! May involve stake-holders -- end-users, managers, engineers involved in maintenance, domain experts, trade unions, etc. 35 36
Problems of Analysis The Spiral! Stake-holders don!t know what they really want.! Stake-holders express requirements in their own terms.! Different stake-holders may have conflicting requirements.! Organisational and political factors may influence the system requirements.! The requirements change during the analysis process. New stake-holders may emerge and the business environment change. classification and organisation discovery prioritization and negotiation documentation 37 38 Process Activities! discovery ~ Interacting with stake-holders to discover their requirements. Domain requirements are also discovered at this stage.! classification and organisation ~ Groups related requirements and organises them into coherent clusters.! Prioritisation and negotiation Validation! Concerned with demonstrating that the requirements define the system that the customer really wants.! error costs are high so validation is very important ~ Fixing a requirements error after delivery may cost up to 100 times the cost of fixing an implementation error. ~ Prioritising requirements and resolving requirements conflicts.! documentation ~ are documented and input into the next round of the spiral. 39 40
Checking! Validity. Does the system provide the functions which best support the customer!s needs?! Consistency. Are there any requirements conflicts?! Completeness. Are all functions required by the customer included?! Realism. Can the requirements be implemented given available budget and technology! Verifiability. Can the requirements be checked? Validation Techniques! reviews ~ Systematic manual analysis of the requirements.! Prototyping ~ Using an executable model of the system to check requirements. Covered in Chapter 17.! Test-case generation ~ Developing tests for requirements to check testability. 41 42 Process variability! The level of detail required in a requirements specification differs greatly depending on the type of product that is being developed ~ A railway signalling system is a very detailed specification that can be validated by authorities outside of the organisation procuring the software ~ A computer game specification is a storyboard with pictures and examples! They use completely different processes involving different types of people to derive these specifications! Scope for process standardisation and support is therefore limited Doing It the AGILE Way 43
the Agile Approach Agile Engineering! documents are usually insufficient, regardless of how much effort goes into it Developer! Investment in detailed documentation early in the project will be wasted when the requirements inevitably change Identify idea or suggestion Discuss potential requirement Estimate Model and document Prioritise User 45 46 Agile Gathering! High level requirements what should the system as a whole really do? ~ Usage model -- a collection of user stories ~ Initial domain model class responsibility collaborator (CRC) cards, a slim UML class diagram ~ User interface model screen sketches, or maybe a user interface prototype! What level of detail do you actually need? ~ Just enough to get the big picture ~ The initial requirements are later analysed, on a just-in-time basis Best Practices! Stake-holders actively participate! Take a breadth-first approach ~ 45% of features are never used, 19% are rarely used, and 16% are sometimes used...! Model-storm details just-in-time ~ are identified throughout most projects! Your goal is to implement requirements, not to document them ~ Barely just enough! Smaller is better ~ Smaller is easier to estimate 47 48
Best Practices (cont!d)! Adopt stake-holder terminology! Keep it fun! Obtain management support! Turn stake-holders into developers! Treat requirements like a prioritised stack Challenges! Limited access to project stake-holders! Project stake-holders don!t know what they want! Conflicting priorities! Too many project stake-holders want to participate! Project stake-holders prescribe technology solutions! Project stake-holders are unable to see beyond the current situation 49 50 Challenges, cont!d! Project stake-holders are afraid to be pinned down! Project stake-holders don!t understand modelling artefacts! Developers don!t understand the problem domain! Developers don't understand the requirements End of Today!s Lecture Thanks for your attention! 51 47