what is a requirement a property or behavior

what is a requirement? “a property [or behavior] that must be exhibited in order to solve some problem of the real world” SWEBOK ch 2 requirements must be: • clearly and formally stated • approved and prioritized • validated • subject to configuration management University of Toronto at Scarborough © Kersti Wain-Bantin CSCC 40 requirements 1

examples of requirements too vague. . . • backorders are permitted • the call centre must be more efficient • system must have a low probability of failure why? much better. . . • up to 5 backorders can be created from a single original order • the system must increase the call centre’s throughput by 20% • probability of failure for any operation is less than 1*10 -8 University of Toronto at Scarborough © Kersti Wain-Bantin CSCC 40 requirements 2

classification of requirements functional emergent property general requirement product high priority broad scope (architectural) volatile VS VS non-functional specific task specific stakeholder need process optional narrow scope (specific component) stable some requirements have emergent properties; they depend for their satisfaction on how well the system components inter-operate University of Toronto at Scarborough © Kersti Wain-Bantin CSCC 40 requirements 3

what do specifications tell you? functional What does the system have to do? For whom? What information is needed? By whom? When are the functions and data needed? non-functional What is the structure of the system? What performance and capacity is needed? control How does the system react to external events? How does the system respond to unexpected events or data? What is the event flow in the system? The above are answered using text and diagrams. University of Toronto at Scarborough © Kersti Wain-Bantin CSCC 40 requirements 4

the main challenge is complexity Where does one system end another start? If a system is a view of reality, who’s view do we work with? What if the system is too large to be understood by any one person? How do we handle the continuous change in technology? How do we handle requirements that change? How do we cope with new development tools, techniques and methodologies? our main defense is abstraction and decomposition! University of Toronto at Scarborough © Kersti Wain-Bantin CSCC 40 requirements 5

abstraction is the main tool used in reasoning about software because. . . • you can ignore inconvenient detail • abstraction simplifies the problem (but doesn’t solve it) how do you define an abstraction? name and describe the functionality at several levels. . . • by describing the desired outcome • by describing the pre-conditions and post conditions source: S. Easterbrook CSC 444 2001 University of Toronto at Scarborough © Kersti Wain-Bantin CSCC 40 requirements 6

abstraction and decomposition decompose the problem (requirement) so that: • each subproblem is at (roughly) the same level of detail • each subproblem can be solved independently • the solutions to the subproblems can be combined to solve the original problem why? • different people can work on different subproblems • development and maintenance is easier is decomposition always possible? • not for some complex, impossible or trivial problems source: S. Easterbrook CSC 444 2001 University of Toronto at Scarborough © Kersti Wain-Bantin CSCC 40 requirements 7

decomposition and information hiding 1. identify components minimize dependencies between components, striving for. . . • low coupling (measure of inter-component connectivity) • high cohesion (measure of how well the contents of a component go together) hide information so that. . . • components keep their data private • components keep their methods (logic) private 2. model the problem using formal diagrams that show. . . • flow of data and control between components • states of components • system architecture source: S. Easterbrook CSC 444 2001 University of Toronto at Scarborough © Kersti Wain-Bantin CSCC 40 requirements 8

why modularity? criteria for modularity • compatible • reusable • extendible • reliable • correct • robust • efficient • inexpensive • portable • timely • decomposability • understandability • continuity • protection • information hiding • weak coupling • few interfaces • open-closed principle University of Toronto at Scarborough © Kersti Wain-Bantin CSCC 40 requirements 9

how to elicit requirements? analyst the ideal investigator. . . • saves all the evidence • logs his research • can back up his claims with evidence • questions everything • remains impartial, with no preconceived ideas • isn’t constrained by assumptions or tradition • pays attention to detail • is open to new methods and new interpretations University of Toronto at Scarborough © Kersti Wain-Bantin CSCC 40 requirements 10

inspection and information gathering • organization charts • business mission and strategy statements • interview transcripts • observation notes • planning session results • documentation of old system • CASE repository documents • prototype models • meeting minutes • training manuals • policies and procedure manuals • sample reports, forms • consultants’ reports • questionnaire responses • etc. University of Toronto at Scarborough © Kersti Wain-Bantin CSCC 40 requirements 11

what can we learn? • facts and figures • relevance of facts and figures • reasons for ways of doing things • ideas for the future • constraints • allocation of responsibilities • problems to avoid or solve • directions to take • opportunities • priorities • rules and laws warning: watch out for the differences between • the formal and informal • the official and unofficial University of Toronto at Scarborough © Kersti Wain-Bantin CSCC 40 requirements 12

methods of elicitation • reading, reading • interviews • observation • questionnaires • group support systems • joint application design • prototyping • business process re-engineering • disruptive technologies / paradigm shift University of Toronto at Scarborough © Kersti Wain-Bantin CSCC 40 requirements 13

Joint Application Design (JAD) purpose: to discuss and review system requirements location: off site attendees: leader/chairman, users, managers, sponsors, systems analysts, scribe, advisors as necessary tools used: CASE and planning aids outcomes: designs, functional requirements, operational plans, solutions to problems… agreement, documentation University of Toronto at Scarborough © Kersti Wain-Bantin CSCC 40 requirements 14

group support systems (GSS) Group members type suggestions, questions everyone can read them and respond prototyping iterative process to improve the systems’ design provides “hands on” walkthroughs for reality checking fast response to suggestions ideal for decision support systems and new business venture systems difficult to produce useful documentation shared data and system interfaces difficult to handle some systems requirements get forgotten users want to use the prototype University of Toronto at Scarborough © Kersti Wain-Bantin CSCC 40 requirements 15

business process reengineering Reorganize the flow of data in the organization and change the way work is performed in order to eliminate steps and/or become more responsive to future change Ask the following questions about all activities: How important is it? How dysfunctional is it? Can it be eliminated or improved? disruptive technologies = paradigm shifts and radical ideas University of Toronto at Scarborough © Kersti Wain-Bantin CSCC 40 requirements 16

requirements validation and control how do you know the requirements are correct? • formal documentation • prototypes • walkthroughs • formal approvals • prioritization • evaluation criteria • risk analyses what do you do when requirements change? • set up a formal change request • estimate the impact on the benefits and the costs • get formal approval before accepting the change University of Toronto at Scarborough © Kersti Wain-Bantin CSCC 40 requirements 17

the V model system requirements system integration software requirements acceptance test preliminary design analyze and design software integration detailed design level of abstraction University of Toronto at Scarborough code and inspect © Kersti Wain-Bantin component test unit test and integrate time CSCC 40 requirements 18