ObjectOriented Software Engineering Practical Software Development using UML
Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 4: Overview of the Software Process Developing Requirements (adapted from lloseng by Allen Tucker) © Lethbridge/Laganière 2001 Chapter 4: Developing requirements
Software process: the classical lifecycle model Requirements Specifications Design Limitations: - Requirements change - User involvement - Feedback - Slow © Lethbridge/Laganière 2001 Coding/Integration Verification & Validation Deployment Chapter 4: Developing requirements 2
The spiral model (improving the process) Review v 0. 2 V & V v 0. 1 Prototype Coding/ Integration Deployment (v 1. 0) Requirements Specifications Design © Lethbridge/Laganière 2001 Chapter 4: Developing requirements 3
Object oriented design Focus on classes and objects • Methods and messages are subordinate Features • • Hierarchy/reuse Information hiding/abstraction Polymorphism Class and system have state Tools • • Specifications : Java Modeling Language (UML/JML) Design: Universal Modeling Language (UML) Coding: Java V&V: JML and others © Lethbridge/Laganière 2001 Chapter 4: Developing requirements 4
Correctness of software systems Where? • Method level: pre- and post-conditions, loop invariant • Class level: class invariant (class state) • System level: intra-class invariants (system state) When? • Specification and design phases: Develop method and class specifications (JML/UML) • Coding phase: Develop code from the specifications (Java) • V&V phase: Prove (rigorously) that code and specifications are logically equivalent (JML <==> Java) © Lethbridge/Laganière 2001 Chapter 4: Developing requirements 5
UML origins and current status The Unified Modelling Language (UML) is a widely used graphical standard for software modeling Rumbaugh, Jacobson and Booch merged their different notational schemes in 1994 and 1995. In 1997 they formed the Object Management Group (OMG) and started the process of UML standardization (http: //www. omg. org/) The current UML standard is widely supported (e. g. , argo. UML, Omondo UML http: //www. omondo. com/product. html) UML does not fully embrace formal methods (but it is a good deal more formal than its predecessors). © Lethbridge/Laganière 2001 Chapter 4: Developing requirements 6
Domain Analysis The process by which a software engineer learns about the domain to understand the problem: • The domain is the general field of business or technology in which the clients will use the software —E. g. , college/university course registration • A domain expert is a person who has a deep knowledge of the domain —E. g. , the registrar, students, faculty © Lethbridge/Laganière 2001 Chapter 4: Developing requirements 7
Domain analysis document A. B. C. D. E. F. G. H. Introduction Glossary General knowledge about the domain Customers and users The environment Tasks and procedures currently performed Competing software Similarities to other domains © Lethbridge/Laganière 2001 Chapter 4: Developing requirements 8
Business Process Reengineering: A setting for domain analysis A business process is a mix of people, procedures, software, and hardware that surround a domain of activity for that business. Examples: • payroll • accounting • student registration • airline reservations Business Process reengineering (called BPR) is a methodology to redesign a process so that flaws can be corrected, new capabilities added, and operational costs reduced. • A BPR task may take 6 weeks to a year. • A BPR team has different players: managers, staff, software engineers For more information on BPR, see: http: //www. brint. com/BPR. htm © Lethbridge/Laganière 2001 Chapter 4: Developing requirements 9
Sample process: Bowdoin course registration © Lethbridge/Laganière 2001 Chapter 4: Developing requirements 10
Course registration: a Catalog page Course Description: Spanish 210 Division: c = humanities, b = social science, a = science, d = non-Eurocentric Prerequisite © Lethbridge/Laganière 2001 Instructor Chapter 4: Developing requirements Cross-listing course 11
Course registration: the course book (viewable as a PDF) © Lethbridge/Laganière 2001 Chapter 4: Developing requirements 12
A page in the course book Schedule for Spanish 210 b Time slot © Lethbridge/Laganière 2001 Instructor Chapter 4: Developing requirements 13
Course offerings encoded SPAN 210 A c INTRO TO MODERN HISPANIC LITERATURE Cueto-Asin capacity: 25 time slot: MW 11: 30 -12: 55 same as: [LAM 210] SPAN 210 B c INTRO TO MODERN HISPANIC LITERATURE Turner capacity: 25 time slot: TTH 10: 00 -11: 25 same as: [LAM 210] SPAN 325 c SPANISH CIVIL WAR IN LIT AND FILM Cueto-Asin capacity: 15 prerequisites: [SPAN 2(07|08|09|10), SPAN 2(07|08|09|10)] time slot: MW 2: 30 -3: 55 SPAN 330 c POETRY AND EMPIRE Turner capacity: 15 prerequisites: [SPAN 2(07|08|09|10), SPAN 2(07|08|09|10)] time slot: TTH 2: 30 -3: 55 id distrib © Lethbridge/Laganière 2001 title instructor Chapter 4: Developing requirements 14
Time slots There are lots of these… 50 or more Notes: a) time slots are prescheduled for courses, as are classrooms and capacities. b) When a course fills to capacity, noone else can register for it. c) Popular courses are filled using a random process. © Lethbridge/Laganière 2001 … F 13: 30 -15: 25 F 13: 30 -16: 25 TH 08: 30 -11: 25 TH 10: 00 -11: 25 TH 13: 00 -14: 25 TH 13: 00 -15: 55 TH 13: 00 -16: 55 TH 14: 00 -15: 55 TH 14: 30 -16: 25 TH 16: 00 -18: 55 TH 19: 00 -21: 00 M 06: 00 -07: 55 M 06: 30 -08: 25 … Chapter 4: Developing requirements 15
Course registration: sample student card primary choices Student id (Smith) alternates © Lethbridge/Laganière 2001 Chapter 4: Developing requirements 16
Another sample card Primary choices More alternates Student id (Brown) © Lethbridge/Laganière 2001 Chapter 4: Developing requirements 17
Sample card encoded Student id (Smith) Course id Semester/year Num. Choices Priority (row) Selection (column) Lab. Priority 1 041 4 SPAN 210 B: 11 HIST 209: 12 BIO 158: 13 BIO 158 L 2: 131 BIO 158 L 1: 132 ANTH 233: 14 SPAN 210 A: 21 HIST 236: 22 GEO 100: 23 GEO 100 L 1: 231 GEO 100 L 2: 232 ARCH 204: 24 2 041 4 PHIL 112: 11 PHIL 399: 12 MUS 282: 13 MUS 243: 14 PHIL 120: 21 PHIL 229: 22 MUS 127: 24 3 041 4 GOV 245: 11 REL 221: 12 GOV 211: 13 GOV 270: 14 4 041 4 ANTH 248: 11 ANTH 310: 12 REL 219: 13 DANCE 111: 14 5 041 4 CLAS 102: 11 BIO 064: 12 HIST 142: 13 ARTH 223: 14 ARTH 103: 21 HIST 257: 22 IDEP 220: 23 ENG 104: 24 HIST 204: 31 HIST 228: 32 ASIAN 284: 33 © Lethbridge/Laganière 2001 Chapter 4: Developing requirements 18
Current process: sample transcript Student id Pseudonym Class Courses completed or in progress 1 SMITH 2007 courses: ENG 022 A- FR 101 HIST 216 A- HIST 221 A- HIST 206 PHIL 025 A- ANTH 203 BIO 104 ANTH 102 A ANTH 101 A BIO 104 L SPAN 207 L SPAN 209 SPAN 207 A- SPAN 205 B+ 4 JONES 2005 major: [Anthropology, Asian Studies] courses: ECON 101 B+ ES 287 A GEO 103 L GEO 103 B REL 101 B PHYS 162 A ARTH 010 B ANTH 253 A- ANTH 203 ASIAN 272 ARTH 110 B ARTH 101 B+ ANTH 101 A VART 180 L ANTH 257 ANTH 231 B+ ASIAN 227 B+ ASIAN 273 A ANTH 102 B+ ASIAN 276 L VART 180 B ASIAN 276 B+ ASIAN 370 ARTH 242 B+ ANTH 235 B ANTH 201 B REL 223 A 5 BROWN 2008 courses: ECON 014 FR 205 HIST 218 REL 101 © Lethbridge/Laganière 2001 Chapter 4: Developing requirements 19
Starting Points for Software Projects green field project © Lethbridge/Laganière 2001 Chapter 4: Developing requirements 20
Defining the Problem and the Scope A problem can be expressed as: • A difficulty the users or customers are facing, • Or as an opportunity that will result in some benefit such as improved productivity or sales. The solution to the problem normally will entail developing software A good problem statement is short and succinct © Lethbridge/Laganière 2001 Chapter 4: Developing requirements 21
Problem statement sketch: Bowdoin’s Student registration system (Stress) Strengths Advising Equity Simplicity Scheduling stability Weaknesses Tedious, time-consuming, costly, and error-prone —Students fill out their cards by hand —Registrar keys all 1600 cards into a single batch Access —Students off campus have difficulty registering Does not utilize a modern campus network or on-line technology © Lethbridge/Laganière 2001 Chapter 4: Developing requirements 22
Defining the Scope Narrow the scope by defining a more precise problem • List all the things you might imagine the system doing —Exclude some of these things if too broad —Determine high-level goals if too narrow Example: A university/college registration system © Lethbridge/Laganière 2001 Chapter 4: Developing requirements 23
What is a Requirement? A capability of the system that all stakeholders agree must be present before the customer’s problem is solved. Two types: 1. Functional requirements — describe what the system should do 2. Non-functional requirements — Constraints that control development A collection of requirements is a requirements document. © Lethbridge/Laganière 2001 Chapter 4: Developing requirements 24
Requirements document. . . A. B. C. D. E. Problem Background information Environment and system models Functional requirements Non-functional requirements © Lethbridge/Laganière 2001 Chapter 4: Developing requirements 25
Functional requirements include: 1. What inputs the system should accept 2. What outputs the system should produce 3. What data the system should store that other systems might use 4. What computations the system should perform 5. Timing and synchronization of 1 -4 © Lethbridge/Laganière 2001 Chapter 4: Developing requirements 26
Non-functional requirements 1. Constraints reflecting the system’s performance: —Responsiveness and throughput —Resource utilization —Reliability; recovery from failure —Availability —Maintainability, enhancement, reusability 2. Constraints reflecting the system’s environment. —Platform —Technology to be used (OS, language, IDE, tools) 3. Categories constraining the project plan and development methods —Process (e. g. , OO, Extreme/agile) —Cost (e. g. , programmers, software designers) —Calendar (deadlines) © Lethbridge/Laganière 2001 Chapter 4: Developing requirements 27
Stress. Free = “Stress Fully Reengineered” Goal: To design an on-line course registration system that would meet the following functional requirements: 1. 2. 3. Reduce tedium, cost, and errors: Students can select and enroll in courses on-line Students, registrar, and instructors can see ü current enrollment information ü current major requirements Students can see their transcripts Student/advisor interaction (e. g. , digital signatures) Improve access: On-campus (24/7 access) and off-campus (Internet access) Simultaneous multi-user access Continuous access throughout registration week (eliminate “Phase II”) Utilize modern technology: Internet, client-server framework, database, GUI interface - Use Java, UML, and JML modeling tools © Lethbridge/Laganière 2001 Chapter 4: Developing requirements 28
Stress. Free design elements Requirements document Use case definitions (UML) GUI interface prototype (Java) Database access prototype (Java) Class specifications (UML) Interaction and activity diagrams (UML) Design by contract specifications (JML) Presentation: December 15, 2005 © Lethbridge/Laganière 2001 Chapter 4: Developing requirements 29
Requirements Gathering Techniques Learning —Reading documents and discussing with users —Shadowing users as they do their work Interviewing stakeholders —Ask about details, alternative models, other sources —Gain their confidence! Prototyping —Paper prototype – pictures of the system shown to users —User interface mockup – written in a rapid design language (Java) Developing use cases —Actors: the classes of users that will use the system —Tasks: that each actor will perform with the system © Lethbridge/Laganière 2001 Chapter 4: Developing requirements 30
E. g. , Use cases for Stress. Free requirements Actors include: —Registrar —Student —Instructor Tasks include: —View transcript —View courses offered —View class list —Add a course —Drop a course © Lethbridge/Laganière 2001 Chapter 4: Developing requirements 31
Developing a requirements document • Level of detail depends on: —system size, interfaces to other systems, audience, level of user expertise with the domain and the technology • Requirements should: —Have benefits that outweigh the costs of development —Be important for the solution of the current problem —Be expressed clearly and consistently —Be unambiguous, logically connected and verifiable —Lead to a system of sufficient quality —Be realistic with available resources —Be uniquely identifiable —Not over-constrain the system design © Lethbridge/Laganière 2001 Chapter 4: Developing requirements 32
Risks in Requirements Analysis • Lack of understanding of the domain or the real problem —Do domain analysis and prototyping • Requirements change —Perform incremental development, build flexibility into the design, do regular reviews • Too many requirements (attempting to do too much) —Document the boundaries early, estimate time carefully • Requirements can conflict with each other —Brainstorming, competing prototypes • Some requirements are hard to state precisely —Break requirements into simple sentences and review them carefully; make prototypes early © Lethbridge/Laganière 2001 Chapter 4: Developing requirements 33
- Slides: 33