Contents Ø Introduction 4 Ø Engineering Ø Project Management Ø Software Design Ø Detailed Design and Coding Ø Quality Assurance Engineering Ø What is a Requirement? Ø RE Activities Ø Documentation Ø RE Methods and Notations Ø Examples Analysis Design Coding Testing Specification Installation Planning Operation and Maintenance PVK-02 bella@cs.umu.se 1 PVK-02 bella@cs.umu.se 2 What is a requirement? Functional requirements q A Requirement is something that the product must do or a quality that the product must have. q Three kinds of requirements: o those that absolutely must be met o those that are highly desirable but not necessary o those that are possible but could be eliminated Describe what the system should do o What inputs the system should accept o What outputs the system should produce o What data the system should store that other systems might use o What computations the system should perform o The timing and synchronization of the above PVK-02 bella@cs.umu.se 3 PVK-02 bella@cs.umu.se 4
Non-Functional Non functional requirements are properties or qualities the product must have. q Product qualities: o Usability o Efficiency Performance Space o Reliability o Portability o Cultural and political o Legal requirements o... Constraints q Constraints are global issues that shape the requirements q Examples: Programming languages Operating system The users of the product... PVK-02 bella@cs.umu.se 5 PVK-02 bella@cs.umu.se 6 Examples 1. System shall communicate with external system X. 2. The product shall run on the company s existing Unix machines. 3. The system must have a file containing a complete list of students that is accessible only by the teacher. 4. The product should be user friendly......new users should be able to add buttons within 30 minutes of their first attempt at Functional Constraint Functional and 2 non functional Non Functional RE Activities q Acquire and identify requirements o Study the system / organisation o Study available documents o Ask users / domain experts Questionnaires Interviews q Analyse and evaluate requirements o Domain analysis o Prototyping o JAD o Scenario modelling q Document requirements q Review and validate requirements using the product. 7 PVK-02 bella@cs.umu.se 8
Definition Definition Definition Definition x x x x x x Specification x x Specification xx Specification xx xx Specification xx xx xx xx xx xx xx xx xx xx xx xx Definition Definition Definition Definition x x x x x x x x Specification xx Specification xx Specification xx Specification xx xx xx xx xx x xx xx xx xx xx xx xx xx Purpose of the Document q Describe external system behaviour o Functional requirements o User interface o Acceptable responses to undesired events q Describe system properties o Non-functional requirements o Acceptance criteria Ł Implementation independent reference Ł Specifies the WHAT and not the HOW guide design guide analysis Ł Part of the contract between customer and developer PVK-02 bella@cs.umu.se 9 Types of Document Two extremes: An informal outline of the requirements using a few paragraphs or simple diagrams requirements definition A long list of specifications that contain thousands of pages of intricate detail requirements specification o documents for large systems are normally arranged in a hierarchy x x xx xx subsystem 1 subsystem 2 x Definition x x xx x Specification xx xx xx x xx sub-subsystems xx sub-subsystems PVK-02 bella@cs.umu.se 10 xx Format of a Document A. Problem B. Background information C. Operational Environment D. Functional E. Non-functional requirements F. Constraints Volere Specification Template http://www.systemsguild.com/guildsite/robs/template.html PVK-02 bella@cs.umu.se 11 Writing Style Do not use vague terms or verbs like some, obviously, usually, often, it follows that, Make sure that uncompleted lists are understood completely (e.g. etc., and so on,,...) Make sure that ranges are clearly understood, e.g. what means in the range of 1 to 100 Ask for clear definitions of terms like always, never, almost, etc. Use pictures and examples to aid in understanding Explain all of your terminology Use shall, must, should, consistently PVK-02 bella@cs.umu.se 12
review q Review goals and objectives of system. q Compare requirements with goals and objectives. q Describe operational environment. q Check for omissions, incompleteness, inconsistency. q Document risks. q Discuss how system will be tested. Engineering Ø What is a Requirement? 4 Ø RE Activities 4 Ø Documentation 4 Ø RE Methods and Notations Ø Examples 13 PVK-02 bella@cs.umu.se 14 Classical Approaches to RE q Problems: o Coping with size Structured approach Stepwise refinement Hierarchical organisation o Coping with change Logic model Maintainable results o Coping with documentation Simple notation Graphical elements q Solutions: o SA (75/75) Function-oriented o ER (end 70s) Data-oriented o SA/RT (85/87) Control-oriented o Integrated approaches SA/ER/RT (end 80s) OO/RT (early/mid 90s)??? Systematic approaches to requirements analysis and definition PVK-02 bella@cs.umu.se 15 Structured Analysis (SA) q Developed 1975/76 o DeMarco/Yourdon o Gane/Sarson q System = Process transforming input into output q Hierarchical, logical system model o Processes o Data flows o Data stores o Terminators q Notation: o Data flow diagrams (DFDs) o Data dictionary (DD) o Process specifications (PSpecs) 16
Gane/Sarson data item(s) Data Flow Diagrams Terminator: Source or destination of data/information. Outside the system boundaries. Data flow: Flow of data. Process: Transforms input data flow(s) into output data flow(s). Data store: Data repository. DeMarco/Yourdon data item(s) PVK-02 bella@cs.umu.se 17 DFD Development q Start with a context diagram q Successively refine processes q Describe all data in the data dictionary q Describe all atomic processes by PSpecs q Example: Order processing Customer order invoice package data process orders credit status customer data refine Customer order package data verify if order is valid credit status customer data assemble available and invoice packages order invoice PVK-02 bella@cs.umu.se 18 DFDs--Managing Complexity DFD hierarchy + numbering/naming rules + balancing rules Level n Leveled DFDs - Example 1 1.1 structure Level n+1 Data Storage Level n+2 PVK-02 bella@cs.umu.se 19 1.3 1.2 PVK-02 bella@cs.umu.se 20
DFDs-- Forbidden Structures The SAnotation is not formally defined Rules are defined by experiences and tool features In-data only Terminator-to-terminator flows DFD Naming and Balancing Context diagram Level 0 Term input System output 0 System Level 1 other data Do Y input Do X output 2 1 data some data Do Z 3 Out-data only Store-to-store flows Cycles Unnamed dataflows (exception: from/to data stores) All names must be unambiguous. Numbering scheme helps to find processes in the hierarchy DoC:3.3 Do Z Level 2 d2 data Do A.1 d1 Do C astore.3 Do B.2 d3 d6 In data dictionary: some data = d5 + d6 (alternatively: some data = d5 d6) d5 PVK-02 bella@cs.umu.se 21 PVK-02 bella@cs.umu.se 22 PSpecs and DD q The format of PSpecs is not restricted o Free text o Pseudocode q PSpecs must be defined for all atomic processes q The format of the DD is semi-formal q Example: selection (or) telephone number = [ local extension outside number ] local extension = 2 + { number } 3 composition (and) outside number = 0 + [ local number long distance number ] local number = prefix + access number optional long distance number = (1) + area code + local number prefix = [ 123 124 125 ] access number = { number } 4 repetition number = * any number between 0 and 9 * a comment PVK-02 23 SA--Summary q Advantages o Simple notation o Supports hierarchical decomposition o Easy to understand o Good communication medium o Supports consistency checks q Disadvantages o Not well defined o No common guidelines o Many dialects o Incomplete Very poor data descriptions No description of control flows PVK-02 bella@cs.umu.se 24
State Transition Diagram (STD) STDvs. DFD start S1 condition action S2 stop 1 X State X signal Activity bubble2 State 1 2 Y Y signal St State 2 2 3 Activity bubble3 State 3 PVK-02 bella@cs.umu.se 25 PVK-02 bella@cs.umu.se 26 Data Modelling q The entity-relationship (ER) model was developed by Chen (late 70s) to support data(base) modelling q Focuses only on the static structure of data q Notation o Entity-relationship diagrams (ERDs) o Attribute dictionary PVK-02 bella@cs.umu.se 27 ERDNotation q According to Chen + common extensions m Entitytype Relationship type Attribute n Set of real or abstract things about whichdataisstored Set relations between entities with cardinalities m and n. Information that is stored along with entities and relationships. Composition of entities. Classification between entity- and relationship types. PVK-02 bella@cs.umu.se 28
ERD--An Example Name Address Rank Attribute Dictionary Attribute structures TeamMember = Name, Address, Rank; Employee =...;... Attribute types Name = STRING; Address = STRING;... Employee Team Member External n Responsibility 1.. 3 h/week Equipment SWProject Documents PVK-02 bella@cs.umu.se 29 m n Process SA/ER Integration DFDs ProjectTeam ERDs Name Address Rank Data Dictionary Employee Team Member External ProjectTeam = { TeamMember } n TeamMember = Name + Address + Rank... Responsibility n Responsibility 1..3 SWProject PVK-02 bella@cs.umu.se 30 ERM--Summary q Advantages o Simple notation o Supports hierarchical and structural decomposition o Easy to understand o Good communication medium o Well understood o Widely used o Good tool support Ł Well-suited for DB design Extensions of ERM lead to OO approaches q Disadvantages o No behaviour descriptions o No control descriptions Ł Almost useless for non- DB applications PVK-02 bella@cs.umu.se 31 Use Case Modelling q Actor: external person, organization, or system communicating with the system (data exchange) q System boundary: Collection of all use cases q Use case: action that is triggered by an actor or produces a result for an actor q Use case description: textual or semi-formalized description of a use case content Actor Use case PVK-02 bella@cs.umu.se 32
Use Case Diagram Student Sign on for exams Take exam Student Secretary Administer marks Schedule lectures Prof Dean PVK-02 bella@cs.umu.se 33