Contents Introduction Requirements Engineering Project Management Software Design

Contents Introduction Requirements Engineering Project Management Software Design Detailed Design and Coding Quality Assurance Maintenance PVK-04 bella@cs. umu. se 1

Requirements Engineering What is a Requirement? RE Activities Requirements Analysis Planning Design Requirements Documentation RE Methods and Notations Coding Testing Installation Operation and Maintenance Examples PVK-04 Specification bella@cs. umu. se 2

What is a requirement? A Requirement is something that the product must do or a quality that the product must have. Three kinds of requirements: o Functional Requirements o Non functional requirements o Constraints PVK-04 bella@cs. umu. se 3

Examples 1. System shall communicate with external system X. Functional 2. The product shall run on the company’s existing Unix machines. Constraint 3. The system must have a file containing a Functional complete list of students that is accessible and non only by the teacher. functional 4. The product should be user friendly. . . Non. . . new users should be able to add buttons Functional within 30 minutes of their first attempt at using the product. PVK-04 bella@cs. umu. se 4

RE Activities Acquire and identify requirements o Study the system / organisation o Study available documents o Ask users / domain experts • Questionnaires • Interviews Analyse and evaluate requirements o o Domain analysis Prototyping JAD / JAW Scenario modelling Document requirements Review and validate requirements PVK-04 bella@cs. umu. se 5

Why Do Projects Fail? PVK-04 bella@cs. umu. se Study by the Standish Group involving 350 companies from 1994/95, see [Pfleeger 98]. 6

Purpose of the Requirements Document Describe external system behaviour o Functional requirements o User interface o Acceptable responses to undesired events Describe system properties o Non-functional requirements o Acceptance criteria guide design guide analysis à Implementation independent reference à Specifies the WHAT and not the HOW à Part of the contract between customer and developer PVK-04 bella@cs. umu. se 7

Format of a Requirements Document q Problem q Background information q Operational Environment q Functional Requirements q Non-functional requirements q Constraints Volere Requirements Specification Template http: //www. systemsguild. com/Guild. Site/Robs/Template. html PVK-04 bella@cs. umu. se 8

Documenting Requirements is Important Quality factors for requirements documents o Understandable by users and developers o Correct PVK-04 o. Realistic o. Testable o Consistent o. Traceable o Complete o. Prioritised bella@cs. umu. se 9

Requirements 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-04 bella@cs. umu. se 10

Requirements Engineering What is a Requirement? RE Activities Requirements Documentation RE Methods and Notations Examples PVK-04 bella@cs. umu. se 11

Classical Approaches to RE Problems: Solutions: o Coping with size o SA (75/75) Structured approach Stepwise refinement Hierarchical organisation Function-oriented o ER (end 70 s) Data-oriented o Coping with change o SA/RT (85/87) Logic model Maintainable results Control-oriented o Coping with documentation o Integrated approaches Simple notation Graphical elements SA/ER/RT (end 80 s) OO/RT (early/mid 90 s) ? ? ? Systematic approaches to requirements analysis and definition PVK-04 bella@cs. umu. se 12

Structured Analysis (SA) Developed 1975/76 o De. Marco/Yourdon o Gane/Sarson System = Process transforming input into output Hierarchical, logical system model o o Processes Data flows Data stores Terminators Notation: o Data flow diagrams (DFDs) o Data dictionary (DD) o Process specifications (PSpecs) 13

Data Flow Diagrams Gane/Sarson De. Marco/Yourdon Terminator: Source or destination of data/information. Outside the system boundaries. data item(s) Data flow: Flow of data item(s) Process: Transforms input data flow(s) into output data flow(s). Data store: Data repository. PVK-04 bella@cs. umu. se 14

DFD Development Start with a context diagram Successively refine processes Describe all data in the data dictionary Describe all atomic processes by Pspecs Example: Order processing package data order process Customer orders invoice refine Customer order verify assemble available if order is and invoice packages valid order credit status invoice customer data PVK-04 bella@cs. umu. se 15

DFDs--Managing Complexity DFD hierarchy + numbering/naming rules + balancing rules Level n structure Level n+1 Level n+2 PVK-04 bella@cs. umu. se 16

DFDs--“Forbidden” Structures The SA notation is not formally defined Rules are defined by experiences and tool features In-data only Terminator-to-terminator flows Out-data only Cycles Store-to-store flows PVK-04 Unnamed dataflows (exception: from/to data stores) bella@cs. umu. se 17

DFD Naming and Balancing Context diagram Term Level 0 input System output 0 System Level 1 other data Do Y input Do X 2 output 1 some data Do Z 3 Do Z All names must be unambiguous. Numbering scheme helps to find processes in the hierarchy Do C: 3. 3 data Do A. 1 d 1 a store Level 2 d 2 Do C. 3 Do B. 2 d 3 d 6 In data dictionary: some data = d 5 + d 6 (alternatively: some data = d 5 | d 6) d 5

PSpecs and DD The format of PSpecs is not restricted o Free text o Pseudocode PSpecs must be defined for all atomic processes The format of the DD is semi-formal Example: PVK-04 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 19

SA--Summary Advantages o o o Simple notation Supports hierarchical decomposition Easy to understand Good communication medium Supports consistency checks o o Not well defined No common guidelines Many dialects Incomplete Disadvantages PVK-04 • Very poor data descriptions • No description of control flows bella@cs. umu. se 20

Data Modelling The entity-relationship (ER) model was developed by Chen (late 70 s) to support data(base) modelling Focuses only on the static structure of data Notation o Entity-relationship diagrams (ERDs) o Attribute dictionary PVK-04 bella@cs. umu. se 21

ERD Notation According to Chen + common extensions Entitytype Set of real or abstract things about which data is stored m Relation- n ship type Set relations between entities with cardinalities m and n. Attribute Information that is stored along with entities and relationships. Composition of entities. Classification between entity- and relationship types. PVK-04 bella@cs. umu. se 22

ERD--An Example Name Address Rank Team Member n Responsi-1. . SWProject bility 3 Employe e Attribute Dictionary h/week External Attribute structures Team. Member = Name, Address, Rank; Employee =. . . ; . . . Attribute types Name = STRING; Address = STRING; . . . PVK-04 Equipment bella@cs. umu. se m Responsi- n bility Document s 23

SA/ER Integration DFDs Process ERDs Name Address Project. Team Rank Team Member n Responsi-1. . SWProje ct bility 3 Employe e External Data Dictionary PVK-04 Project. Team = { Team. Member }n Team. Member = Name + Address + Rank. . . bella@cs. umu. se 24

ERM--Summary 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 Disadvantages o No behaviour descriptions o No control descriptions Almost useless for non. DB applications Well-suited for DB design Extensions of ERM lead to OO approaches PVK-04 bella@cs. umu. se 25

Use Case Diagram Student Sign on for exams Take exam Secretary Administer marks Schedule lectures Dean PVK-04 Student bella@cs. umu. se Prof 26

Popularity of (Classical) Methods Study from 1990, see [Yourdon 92]. bella@cs. umu. se 27

References Yourdon, E. (1989). Modern structured analysis. Englewood Cliffs, N. J. : Yourdon Press. Page-Jones, M. (1988). The Practical Guide to Structured Systems Design. Englewood Cliffs, N. J. : Yourdon Press. Kaufmann, A. (2000). Transcript for Systems Analysis Lecture. University of Applied Sciences Giessen-Friedberg Simons, A. (2000). Use Cases Considered Harmful Dept. of Computer Science, University of Sheffield http: //www. smartdraw. com/resources/centers/software/ssadm. htm http: //www. canberra. edu. au/~sam/whp/datadict. html http: //www. softwaremagazin. de/Programmierung/Methoden/SA/body_sa. html http: //www. sims. berkeley. edu/courses/is 208/s 01/Lectures/208 dataflowdgm. ppt http: //www. cis. ohio-state. edu/~bbair/516 http: //www. bus. iastate. edu/hndrcksn/MIS 538 PVK-04 bella@cs. umu. se 28