1. PVK-051 Contents Introduction Requirements Engineering Project Management Software Design Detailed Design and Coding Quality Assurance Maintenance

2. PVK-052 Requirements Engineering What is a Requirement? RE Activities Requirements Documentation RE Methods and Notations Examples

3. PVK-053 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: oFunctional Requirements oNon functional requirements oConstraints

4. PVK-054 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..... Functional Constraint Non Functional Functional and non functional.....new users should be able to add buttons within 30 minutes of their first attempt at using the product. Examples

5. PVK-055 Acquire and identify requirements oStudy the system / organisation oStudy available documents oAsk users / domain experts Questionnaires Interviews Analyse and evaluate requirements oDomain analysis oPrototyping oJAD / JAW oScenario modelling Document requirements Review and validate requirements RE Activities

6. PVK-056 Why Do Projects Fail? Study by the Standish Group involving 350 companies from 1994/95, see [Pfleeger 98].

7. PVK-057 Describe external system behaviour oFunctional requirements oUser interface oAcceptable responses to undesired events Describe system properties oNon-functional requirements oAcceptance criteria Implementation independent reference Specifies the WHAT and not the HOW Part of the contract between customer and developer Purpose of the Requirements Document guide analysis guide design

8. PVK-058 Format of a Requirements Document  Problem  Background information  Operational Environment  Functional Requirements  Non-functional requirements  Constraints Volere Requirements Specification Template http://www.systemsguild.com/GuildSite/Robs/Template.html

9. PVK-059 Quality factors for requirements documents oUnderstandable by users and developers oCorrect oConsistent oComplete Documenting Requirements is Important oRealistic oTestable oTraceable oPrioritised

10. PVK-0510 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

11. PVK-0511 Requirements Engineering What is a Requirement? RE Activities Requirements Documentation RE Methods and Notations Examples

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

13. PVK-0513 Structured Analysis (SA) Developed 1975/76 oDeMarco/Yourdon oGane/Sarson System = Process transforming input into output Hierarchical, logical system model oProcesses oData flows oData stores oTerminators Notation: oData flow diagrams (DFDs) oData dictionary (DD) oProcess specifications (PSpecs)

14. PVK-0514 Data Flow Diagrams Gane/Sarson DeMarco/Yourdon 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. data item(s)

15. PVK-0515 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 Customer process orders order invoice refine Customer verify if order is valid order invoice package data customer data credit status available packages assemble and invoice order

16. PVK-0516 DFDs--Managing Complexity structure DFD hierarchy + numbering/naming rules + balancing rules Level n+1 Level n Level n+2

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

18. PVK-0518 DFD Naming and Balancing System 0 Context diagram Level 0 Term input output Do X 1 System Level 1 input output Do Y 2 Do Z 3 some data other data data Do A.1 Do Z Level 2 data d5 Do B.2 Do C.3 d3 d2 d1 a store d6 In data dictionary: some data = d5 + d6 (alternatively: some data = d5 | d6) All names must be unambiguous. Numbering scheme helps to find processes in the hierarchy  Do C: 3.3

19. PVK-0519 PSpecs and DD The format of PSpecs is not restricted oFree text oPseudocode PSpecs must be defined for all atomic processes The format of the DD is semi-formal Example: telephone number = [ local extension | outside number ] local extension = 2 + { number } 3 outside number = 0 + [ local number | long distance number ] local number = prefix + access number long distance number = (1) + area code + local number prefix = [ 123 | 124 | 125 ] access number = { number } 4 number = * any number between 0 and 9 * selection (or) optional repetition a comment composition (and)

20. PVK-0520 SA--Summary Advantages oSimple notation oSupports hierarchical decomposition oEasy to understand oGood communication medium oSupports consistency checks Disadvantages oNot well defined oNo common guidelines oMany dialects oIncomplete Very poor data descriptions No description of control flows

21. PVK-0521 Data Modelling The entity-relationship (ER) model was developed by Chen (late 70s) to support data(base) modelling Focuses only on the static structure of data Notation oEntity-relationship diagrams (ERDs) oAttribute dictionary

22. PVK-0522 ERD Notation According to Chen + common extensions Set of real or abstract things about which data is stored 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. Entitytype Attribute Relation- ship type mn

23. PVK-0523 ERD--An Example Team Member Name Responsi- bility n1..3 External Employee SWProject Documents Equipment Address Rank h/week Responsi- bility mn Attribute Dictionary Attribute structures TeamMember = Name, Address, Rank; Employee =...;... Attribute types Name = STRING; Address = STRING;...

24. PVK-0524 SA/ER Integration ProjectTeam Data Dictionary ProjectTeam = { TeamMember } n TeamMember = Name + Address + Rank... Process DFDs Team Member Name Responsi- bility n1..3 External Employee SWProject AddressRank ERDs

25. PVK-0525 ERM--Summary Advantages oSimple notation oSupports hierarchical and structural decomposition oEasy to understand oGood communication medium oWell understood oWidely used oGood tool support Well-suited for DB design Disadvantages oNo behaviour descriptions oNo control descriptions Almost useless for non- DB applications Extensions of ERM lead to OO approaches

26. PVK-0526 Use Case Diagram Sign on for exams Take exam Student SecretaryDeanStudent Administer marks Schedule lectures Prof

27. PVK-0527 Popularity of (Classical) Methods Study from 1990, see [Yourdon 92].

28. PVK-0528 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.software- magazin.de/Programmierung/Methoden/SA/body_sa.html http://www.sims.berkeley.edu/courses/is208/s01/Lectures/208- dataflowdgm.ppt http://www.cis.ohio-state.edu/~bbair/516 http://www.bus.iastate.edu/hndrcksn/MIS538