SE 430 Object Oriented Modeling Dennis Mumaugh Instructor
SE 430 Object Oriented Modeling Dennis Mumaugh, Instructor dmumaugh@cdm. depaul. edu Office: CDM, Room 428 Office Hours: Thursday, 4: 00 – 5: 30 September 15, 2016 SE 430: Lecture 2 1 of 98
Administrivia § Comments and feedback § Class Participation: Ø Ø Please feel free to ask questions during the lecture. Wave your hand, etc. Let me know you are listening: a nodding of a head, a frown, etc. § Solutions will be posted shortly after they are due. September 15, 2016 SE 430: Lecture 2 2 of 98
SE 430 – Class 2 Topic: Requirements Ø Ø The Unified Process Introduction » Communicating Design: Problem Statement; “Vision” Defining Requirements; The Requirements Workflow » Requirements Analysis; » Business Rules; Reading: Arlow & Neustadt: Ch’s 3 & 14 Articles on the Class Page and Reading List September 15, 2016 SE 430: Lecture 2 3 of 98
The Domain § The problem domain for the assignments and many of the examples in the lecture is The PDQ Bach Museum of Art and Music at the University of Southern North Dakota at Hoople. § The project is to automate the Museum: tracking of collections, membership, climate control, etc. and a Visitor Education system. § A description is on-line for the problem and some references are given in the reading list. Ø See: The Museum Automation Project September 15, 2016 SE 430: Lecture 2 4 of 98
Assignment 1 The Museum Automation Project § Develop project description and requirements document for the Visitor Information Subsystem Ø Ø Ø What is the Museum Automation Project? What is the Visitor Information Subsystem (VIS)? » It is more than just a hand-held device! What is the scope of the VIS? § Check on Google for: mobile context-aware tour guide § See class reading list page for references. § Due September 22, 2016. September 15, 2016 SE 430: Lecture 2 5 of 98
Thought for the Day Whatever can possibly go wrong will. — Murphy's Law Events that are extremely improbable tend to occur at the most inopportune time. [Or, The probability of an event is inversely proportional to its desirability. ] — Gumperson's Law September 15, 2016 SE 430: Lecture 2 6 of 98
Last Time Topics: Ø Ø Ø Important Object-Oriented Concepts Software Development Life Cycle Object-Oriented Analysis & Design September 15, 2016 SE 430: Lecture 2 7 of 98
The Unified Process To be discussed more in lecture 10 September 15, 2016 SE 430: Lecture 2 8 of 98
The Unified Process Iterative software development process derived from Booch, Rumbaugh and Jacobsen's methodology § Use-case based § Risk-driven § Client-driven § Architecture-centric September 15, 2016 SE 430: Lecture 2 9 of 98
Why the Unified Process? § The Unified Process (UP) represents a mainstream approach for software development across the spectrum of project scales § The process is scalable: you need not use the entire framework of the process for every project, only those that are effective § It employs several software best practices: commercially-proven approaches to software development Ø Example: Develop software iteratively § The process is effective: it has been successfully employed on a large population of projects, both in its specific (Rational—RUP) and core forms September 15, 2016 SE 430: Lecture 2 10 of 98
Features of Unified Process § Combines effective elements of earlier O-O processes. § Improves productivity through use of practical methods that you’ve probably used already (but didn’t know it). § Employs: Ø Breadth-first rather than a depth-first approach. Ø Iterative and incremental approach allows start of work with incomplete, imperfect knowledge. Ø Succession of architectural releases as on-going ‘proof of concept. ’ September 15, 2016 SE 430: Lecture 2 11 of 98
Use-case-driven § What is a use case? Ø Ø Ø A prose representation of a sequence of actions Actions are performed by one or more actors (human or non-human) and the system itself These actions lead to valuable results for one or more of the actors— helping the actors to achieve their goals § Use cases are expressed from the perspective of the users, in natural language, and should be understandable by all stakeholders § Use-case-driven means the development team employs the use cases from requirements gathering through code and test September 15, 2016 SE 430: Lecture 2 12 of 98
Architecture-centric § Software architecture captures decisions about: The overall structure of the software system Ø The structural elements of the system and their interfaces Ø The collaborations among these structural elements and their expected behavior § Architecture-centric: software architecture provides the central point around which all other development evolves Ø Provides a ‘big picture’ of the system Ø Provides an organizational framework for development Ø Facilitates reuse Ø Provides a framework for evolving the system by attending to modifiability qualities of the system Ø Guides the prioritization and choice of use cases for development Ø September 15, 2016 SE 430: Lecture 2 13 of 98
Iterative and incremental § An iterative and incremental approach allows start of development with incomplete, imperfect knowledge § An iterative and incremental process is like solving a jigsaw puzzle: neither top-down nor bottom-up but accretionary and convergent § Iterative and incremental the following advantages: Ø Ø Ø Logical progress toward a robust architecture Effective management of changing requirements Effective means to address changes in planning Continuous integration Early understanding of the system (‘Hello world!’ effect) Ongoing risk assessment September 15, 2016 SE 430: Lecture 2 14 of 98
Workflows § Workflows define a set of activities that are performed § Workflows cut across the phases, but with different levels of emphasis in each phase § The core workflows are: Ø Requirements Ø Analysis Ø Design Ø Implementation Ø Test September 15, 2016 SE 430: Lecture 2 15 of 98
The five core workflows § Requirements Ø Ø Ø Develop and refine the problem definition Identify stakeholder needs Define system features to be considered Define the system scope Build the use-case model § Analysis Ø Ø Refine use-case model Define the domain model Define a candidate architecture (transitions to design) Refine the architecture (transitions to design) September 15, 2016 SE 430: Lecture 2 16 of 98
The five core workflows § Design Ø Ø Ø Design the physical realizations of the use cases Develop the design model Develop the deployment model § Implementation Ø Ø Plan subsystem implementation Implement components: classes, objects, etc. Perform unit-level testing Perform component and system integration § Test Ø Ø Build the test model: test cases and expected results Plan, design, implement, execute, and evaluate tests September 15, 2016 SE 430: Lecture 2 17 of 98
Artifacts, Workers, and Activities § These three elements are part of each workflow § An artifact is a piece of information that is used as input to, changed by, or output from a process § Examples include: Ø Ø Ø Models—use-case, domain, and design Model elements—use case, domain class, design class Diagrams and documents Source code Executable elements September 15, 2016 SE 430: Lecture 2 18 of 98
Artifacts, Workers, and Activities Workers (called roles in RUP 2001—a better name) define the behavior and responsibilities of an individual or a team § Examples: Architect, use-case engineer, component engineer, system integrator § Some important distinctions: Ø Ø Ø Workers participate in the development of the system Actors are outside the system and have usage relationships with the system Stakeholders encompass both actors and workers, as well as others involved with the project September 15, 2016 SE 430: Lecture 2 19 of 98
Artifacts, Workers, and Activities are the tasks performed within a workflow § Activities can describe a wide range of abstraction levels, from high-level (‘construct domain model’) to low-level (‘implement class’) § Examples include: Ø Ø Plan iteration Find use cases and actors Execute integration test Review test results September 15, 2016 SE 430: Lecture 2 20 of 98
Software best practices 1. 2. 3. 4. 5. 6. Develop software iteratively Manage requirements Use component-based architectures Visually model software Continuously verify software quality Control changes to software September 15, 2016 SE 430: Lecture 2 21 of 98
Applying the requirements workflow § For the next few classes, we will be concentrating on the requirements workflow, which spans the inception and elaboration phases § In this context, we will discuss: Ø Developing the system overview statement Ø Identifying stakeholders and understanding user goals Ø Building a feature list for the system Ø Building a system context description Ø Capturing high-level functional requirements via use cases (upcoming lectures) Ø Identifying supplementary (non-functional) requirements Ø Building a glossary (technical dictionary) September 15, 2016 SE 430: Lecture 2 22 of 98
This course § Provides sequence of steps to take Ø Problem Statement and Requirements Ø Use cases Ø System Sequence Diagram Ø Conceptual Model (and CRC cards) Ø Robustness Diagrams Ø Operation Contracts Ø Collaboration/Communication/Interaction Diagrams Ø Use-case Realization and Design Scenarios Ø Class Diagram September 15, 2016 SE 430: Lecture 2 23 of 98
UML September 15, 2016 SE 430: Lecture 2 24 of 98
The Unified Modeling Language § The UML is standard diagramming language to visualize the results of analysis and design. § Notation (the UML) is a simple, relatively trivial thing. § Much more important: Skill in designing with objects. Ø Learning UML notation does not help § The UML is not Ø a process or methodology Ø object-oriented analysis and design Ø guidelines for design September 15, 2016 SE 430: Lecture 2 25 of 98
UML: What's Important? Harmful is knowing how to read and draw UML diagrams, but not being an expert in design and patterns. Important is object and architectural design skills, not UML diagrams, drawing, or CASE tools. September 15, 2016 SE 430: Lecture 2 26 of 98
Summary § Software development processes are undergoing change – new systems are emerging: Ø Ø Iterative development Agile methodologies such as Extreme Programming and Scrum § The object oriented development process offers some challenges Ø Ø applying iterative and incremental development effectively adding new requirements late in the development process § The Unified Process (UP) is an attempt to merge competing methodologies § The Unified Modeling Language is an attempt to merge competing notations. September 15, 2016 SE 430: Lecture 2 27 of 98
Requirements are the “what you want, ” like when your kid says, “I wanna pony. ” Analysis is what you get, as in “You're getting a tricycle. ” September 15, 2016 SE 430: Lecture 2 28 of 98
Requirements “What the customer wanted. ” September 15, 2016 SE 430: Lecture 2 29 of 98
Requirements Analysis As Marketing requested it. September 15, 2016 SE 430: Lecture 2 30 of 98
Requirements Analysis As Sales ordered it. September 15, 2016 SE 430: Lecture 2 31 of 98
Requirements Analysis As Engineering designed it. September 15, 2016 SE 430: Lecture 2 32 of 98
Requirements Analysis As Production manufactured it. September 15, 2016 SE 430: Lecture 2 33 of 98
Requirements Analysis As Maintenance installed it. September 15, 2016 SE 430: Lecture 2 34 of 98
Requirements Analysis What the customer wanted. September 15, 2016 SE 430: Lecture 2 35 of 98
First stage in a project § Typical first phase of a project is the requirements. Ø Ø Before we can do anything we need to know what it is we want to do. We need useful forms of input data. § Sloppy requirements specification and management is a major risk in software development. Ø Ø Majority of project failures can be attributed to incomplete or incorrect requirements. Therefore, worth the effort to do very well. § Requirements capture is an entire course in itself. § It is not an OO activity per se. September 15, 2016 SE 430: Lecture 2 36 of 98
Establishing Requirements § Introduction § Requirements Process Fundamentals § Requirements in the SDLC September 15, 2016 SE 430: Lecture 2 37 of 98
Definitions § A requirement is a statement about an intended system that specifies § § § what the system should do or how the system should perform Stakeholders are those people or organizations that will be affected directly or indirectly by the system, or who will have an effect on the system The phrase establishing requirements represents the understanding that requirements arise from a progressive understanding of stakeholders’ needs A goal of the requirements activity is to make requirements specific, unambiguous, and clear Requirement – a capability needed by a user to solve a problem or achieve an objective Requirements document – an unambiguous (written) description of the external behavior of the system to be built September 15, 2016 SE 430: Lecture 2 38 of 98
The importance of getting requirements right: Standish Group’s CHAOS Report (2009) Rank Successful Challenged Factors Cited % Factors Cited 1 User Involvement 15. 9 2 Executive Management Support 13. 9 3 Clear Statement 13 of Requirements Factors Cited % Lack of User Input 12. 8 Incomplete Requirements 13. 1 Incomplete Requirements 12. 3 Lack of User Involvement 12. 4 Changing Requirements 11. 8 Lack of Resources 10. 6 Definitions: Ø Successful: On-time and on-budget Ø Challenged: Complete and operational, but over-time, over-budget, reduced scope % Standish CHAOS results: - ~32% Successful - ~45% Challenged - ~23% Failure Ø Failure: Cancelled September 15, 2016 Failure SE 430: Lecture 2 39 of 98
Common elements and differences § Sequential, evolutionary, and agile methodologies all treat establishing requirements as one of the most critical elements of the SDLC § The significant differences among the methodologies center on when requirements are established and who is responsible for requirements once they are documented. September 15, 2016 SE 430: Lecture 2 40 of 98
Major kinds of requirements § Functional requirements Ø Ø Ø Are the most readily-understood requirements type Describe what the system should do Are usually active, visible aspects of how the system works § Quality attributes—commonly known as non-functional requirements Ø Ø Support and enhance the functional requirements of a system Examples: Usability, performance, security, availability, modifiability, maintainability (including portability and scalability), testability September 15, 2016 SE 430: Lecture 2 41 of 98
Requirements § Problem Definition —> Requirements Specification Ø Ø Ø Determine exactly what the customer and user want Develop a contract with the customer Specifies what the software product is to do § Difficulties Ø Ø Client asks for wrong product Clients lie [not consciously]. Client is computer/software illiterate Specifications are ambiguous, inconsistent, incomplete September 15, 2016 SE 430: Lecture 2 42 of 98
Why is requirements capture so difficult? § People issues: Ø Ø Ø Developers are usually building software for someone else. Most users have narrow perspective on what system should do. Few users have a broad view of what the system should do. § A solution: develop use cases or ‘stories’ (per ‘agile’ processes)—each itself a narrow view of the system—and ‘stitch’ these views together like a digital panoramic photo September 15, 2016 SE 430: Lecture 2 43 of 98
Why is requirements capture so difficult? § Process issues: Traditionally, requirements were untouchable once analysis had begun, even in projects that have high levels of risk. Ø Requirements are discovered and revised throughout analysis, design, and even into implementation. Ø The best approach to discovering what software should do is to ‘learn by doing. ’ § A solution: iterative and incremental process allows ongoing requirements capture and revision. § Exceptions: Some safety-critical domains (e. g. , medical life-support and public transportation systems) require rigid requirements stability in order to ensure meeting safety and certification requirements Ø September 15, 2016 SE 430: Lecture 2 44 of 98
Requirements § Requirements Capture (A List of Requirements) Delimit the system Ø Form agreement on what the system should do Ø Provide a basis for planning the technical content of iterations Ø Give developers a better understanding of the system § Roles of requirements Ø Describe customer needs and desires for the system. Ø Provide the framework for defining the scope of the system. Ø Identify broad areas of risk, reuse, and systems-level interdependencies. Ø Establish essential contractual obligations. Ø Provide the foundation for testing criteria. Ø Requirements gathering and analysis are not specifically O-O activities Ø September 15, 2016 SE 430: Lecture 2 45 of 98
Features and requirements § A feature is defined as an externally observable service provided by the system that directly fulfills a stakeholder need Ø ‘Feature’ and ‘high-level requirement’ are often used interchangeably Ø Example: Provide basic trouble-shooting app for customers § A feature may fall under either of the requirements categories, though most are functional § When decomposed, a feature represents one or more logically-related requirements Ø Example: Provide product-specific diagnostic tool § It is often difficult to distinguish between features and requirements, hence the interchangeable use of ‘feature’ and ‘high-level requirement’ Ø Example: A feature for the customer support app is to support email access to support staff ☛ A requirement should be specific enough to allow a developer to easily translate the requirement directly into an implemented solution—it needs no further decomposition September 15, 2016 SE 430: Lecture 2 46 of 98
Inputs to analysis Object oriented methods can’t make up for solving the wrong problem. § We can reduce the risk of solving the wrong problem by collecting requirements data. Three useful forms of requirements data are: Ø Ø Ø text information the problem statement or Problem Charter scenarios that characterize the system's behavior § How to collect requirements Ø Ø Ø Informal discussions Competitive Analysis Laundry list of features § After collecting requirements we can document them in a consistent form: use cases or user stories September 15, 2016 SE 430: Lecture 2 47 of 98
Requirements inputs Some examples of text inputs: Ø Inputs from customers, Ø Market surveys, Ø Standards specifications, Ø Text-based requirements documents, Ø Competitive analysis Ø Architectural documentation Ø Interface specifications Ø Design documents Ø Requirements specifications Ø E-mail messages Ø Lists of system assumptions You need to scan through these documents to find the real requirements. September 15, 2016 SE 430: Lecture 2 48 of 98
I Get Out of Bed, and then I. . . Discovering requirements, delighting customers Goal: Understand how and when your customer uses your product. Activity: Ask your customers to describe their daily events in a way that makes sense to them. You can use a poster-sized date planner or a simple timeline on butcher paper. Make certain you ask them to describe different kinds of days, such as: § The beginnings and ends of weeks, months, quarters or years. § Special events unique to their industry. § Days on which everything goes horribly awry and they need help. While they're doing this, be alert for how your system helps or hinders their day. Materials: Butcher paper, markers and calendars in normal or large print format. September 15, 2016 SE 430: Lecture 2 49 of 98
Risks of customer misconceptions From Simple and Usable: Web, Mobile, and Interaction Design by Giles Colborne (New Riders, 2011): A few years ago I was asked to redesign some software to help car dealers put together a marketing plan. The brief was to merge several components into one, so that a dealer could write a plan in one sitting. Fortunately, a colleague of mine visited some dealerships to talk to the managers about their needs. At the first dealership she visited, the manager sat in an office with a glass front that opened onto the showroom. As they spoke, the manager kept glancing up to scan the showroom. Whenever a customer looked lost, he would hurry out and attend them. It was the same in every dealership she visited: the managers were constantly interrupted by the needs of their customers. Instead of merging the components, we needed to break them into smaller chunks so that the manager could complete them in the short bursts of time they had. Visiting users in their workplaces was vital—if we’d simply imagined the manager at his desk we would have missed the crucial aspects. September 15, 2016 SE 430: Lecture 2 50 of 98
Requirements levels § A requirement represents a form of abstraction: it abstracts functionality. § Like all forms of abstraction, requirements are subject to the perspective of the viewer. § Chosen perspective translates to a requirements level. Ø High-level: Broad with little detail. Example: Track appointments, contacts, and tasks. Ø Mid-level: Typical analysis level. More specific with some details. Example: User may enter contact name, address, and phone number. Ø Low-level: Implementation-level. Specific and detailed. Example: Present user with scrollable time line from which user may choose appointment start time. September 15, 2016 SE 430: Lecture 2 51 of 98
System attributes and constraints § Attributes specify characteristics or dimensions of system requirements – limit designer options § Constraints specify limits or bounds – more flexible § Specify characteristics, dimensions, or limits of system requirements. § Qualitative attributes and constraints: Ø Example: The user interface must be graphical and usable by color-blind persons. § Quantitative attributes and constraints state measurable objectives or metrics for the attribute: Ø Ø Example: The security system must provide coverage for 99. 998% of every operating year (< 11 minutes downtime). Example: The system must have < 11 minutes downtime for every operating year (constraint—flexible target) § Quantitative attributes and constraints are preferable to qualitative ones. September 15, 2016 SE 430: Lecture 2 52 of 98
The Unified Process Requirements Workflow September 15, 2016 SE 430: Lecture 2 53 of 98
UP - Introduction § The UP defines several artifacts: Ø Ø Ø Ø Vision document; charter; project overview Use-case model Supplementary Specifications » Includes requirement lists and attributes Stakeholder requests UI prototype Use-case UI or storyboard Competitive Analysis Glossary § Advice: Create every one! September 15, 2016 SE 430: Lecture 2 54 of 98
Requirements workflow Write System Overview Statement Identify Stakeholders Understand User Goals Develop a Feature List Build a System Context Description Identify Functional Requirements Identify Supplementary Requirements Build a Glossary as You Go September 15, 2016 SE 430: Lecture 2 55 of 98
Problem Charter § The problem charter describes the basic theme of the system to be developed. Also can be a “vision” document or a “Project Overview” § It helps to focus the team § It is a good idea to limit the charter to one page § Example: The product to be developed is a Course Registration Management System (CRMS). Courses are offered both live and via online streaming video. The system will be used by both students and administrators. Students use it for registration and drop procedures for course offerings. The system is used by administrators for managing course and course offering information. September 15, 2016 SE 430: Lecture 2 56 of 98
Start with a Project Overview Statement § Project overview statement should be considered an executive summary or extended abstract, giving the highest-level view of the system § Contains all the essential project elements: Ø Brief project description. Defines the purpose of the project Ø (Optional) Competitive analysis. Ø Project objective(s). Identify concrete accomplishments and/or deliverables » Examples: ‘Reduce prescription fulfillment time by 50%’ or ‘Provide on-line, up-to-date patient medication reports’ Ø Qualitative estimates of benefits and costs. Include both tangibles and intangibles » Examples: ‘Increase patient confidence levels’ or ‘Will require moderate-to-high investment in staff training’ September 15, 2016 SE 430: Lecture 2 57 of 98
Write System Overview Statement § Contains all the essential project elements: Scope. Indicate what capabilities will and will not be included in the project. State the boundaries of a (sub)system if it works with other (sub)systems » Examples: ‘System will monitor all medications prescribed within the hospital network’ or ‘System will not attempt to monitor prescriptions outside the hospital network’ Ø Interfaces. Identify other systems (computer or otherwise) with which the system must interact » Examples: Central patient records and office systems of doctors affiliated with hospital network » This covers electronic connections to third party systems as well as other parts of a “system” that is not part of the current project scope. § Gives the broadest, highest-level picture of the system. Ø September 15, 2016 SE 430: Lecture 2 58 of 98
Scope § Scope refers to two different but related concepts: Ø Product scope represents the features and functions that define the product—what will and will not be included in the product Ø Project scope represents the work that needs to be performed to deliver the product with those features and functions Ø It is clear that product scope and a significant part of project scope are tightly coupled § In any evolutionary process—plan-driven or agile—requirements are expected to evolve with time § Thus, scope of the product and project are viewed as a function of time, rather than as a fixed boundary September 15, 2016 SE 430: Lecture 2 59 of 98
Scope § Scope creep refers to unplanned changes to requirements scope § In a well-managed evolutionary project, there is no scope creep Ø Scope is expected to change Ø Customer is closely involved and understands the total cost of changes Ø New requirements are openly evaluated and incorporated, with minimal administrative overhead September 15, 2016 SE 430: Lecture 2 60 of 98
Scope § Determine the boundaries of the system. What is the system? Ø What is the system’s environment? § Develop a context model that shows the context of the system within its environment. Ø Branch accounting System Branch counter System September 15, 2016 Security System Account Database Auto-Teller System Usage Database Maintenance System SE 430: Lecture 2 61 of 98
Competitive Analysis Normally, this is done before we start requirements § What other products that are similar to ours? § Their features and capabilities § Why is the competitive product Ø Ø Unusable Unacceptable § Cautions Ø Ø Beware of NIH (Not Invented Here) Beware of doing something because we can § COTS (Commercial off the shelf software) § Do other people have similar problems (beware of “our problems are different”)? September 15, 2016 SE 430: Lecture 2 62 of 98
Identify stakeholders § Stakeholders are those people or organizations that will be affected directly or indirectly by the system or who will have an effect on the system § Examples of stakeholders include: Ø Ø Ø The system (non-end-user) customer Various users of the system: end-users, system administrators, configurers, training staff, service staff Development organization, individual developers Marketing, sales, and distribution Opponents and supporters § We will primarily address system customers and users, focusing on the latter September 15, 2016 SE 430: Lecture 2 63 of 98
System customers and users § System customers are those entities responsible for initiating the § § system project and providing material, financial, or staffing resources for system Actual users may be a subset of system customers or may be a completely disjoint set Be as specific as possible in identifying system customers and users Ø Medical records PDA example: Customer will be the hospital or department administration; users will be doctors, nurses, physical therapists, etc. In all cases, be sure to understand user needs and be willing to correct system customer misconceptions May need to reconcile system customer goals and user goals September 15, 2016 SE 430: Lecture 2 64 of 98
Understand user goals § User goals are specific, but not detailed, descriptions of what user wants the system to do. § A user goal may lead to one or more requirements. § User goals provide the foundation for use-case analysis. September 15, 2016 PDA example SE 430: Lecture 2 65 of 98
Develop a feature list § Feature list identifies a list of high- or mid-level requirements, out of a (usually) much larger wish list, that are candidates for inclusion in the system. § For each requirement, provide: Ø Ø Ø Ø Number each feature, e. g. F 003 A name, as descriptive as possible. Description in the form of an explanation or a definition. Associated user goal (optional). A single goal may have more than one requirement associated with it. Priority (required, desirable, or optional). Visibility (visible to user or hidden from user). Estimated implementation risk for this requirement (high, normal, minimal). September 15, 2016 SE 430: Lecture 2 66 of 98
Build a system context description § System context description describes the environment in which the system is embedded. § Identifies entities that are directly relevant to the system: Ø Ø Ø Domain objects. Domain processes. Domain actors. § These are examples of conceptual classes § System context description acts as the foundation for the Domain Model. September 15, 2016 SE 430: Lecture 2 67 of 98
System context: identify domain objects § Domain objects are the entities encountered in the world in which the system will operate. § Domain objects for (Medical) PDA software include: Ø Ø Ø ‘Business’ objects and abstractions: Patient record, appointment record, medication list, synchronization schedule. Real-world objects: Touch screen, synchronization link (e. g. cradle, IR, Bluetooth), host PC Events: Last synchronization date/time with host, create new medication record request, medication alarm notification; anything that occurs within a limited time September 15, 2016 SE 430: Lecture 2 68 of 98
System context: identify domain processes § Discovery of domain processes often proceeds concurrently with § § domain object discovery. Types of domain processes might include: Ø Start-up: Touch screen initialization; set time, time zone, and date. Ø Standard operating procedures: Add/delete PDA database entry, change font size, soft reset. Ø Exceptional circumstances: ‘Hard’ reset, delete private records. For requirements phase, just name and define processes. Do not explore process detail here! This will be captured later in use -case descriptions, sequence diagrams, and statecharts. Sometimes domain processes are very similar to functional requirements. September 15, 2016 SE 430: Lecture 2 69 of 98
System context: identify domain actors § Domain actors interact in some way with the system Ø Ø Ø Users are a subset of domain actors Actors may be active (directly interacting with system) or passive (indirect interaction) Actors may be human or non-human § Examples: Ø Ø Active/human: device user (doctor, nurse, etc. ) Active/non-human: PDA/host synchronization software Passive/human: recipient of consultation reminder Passive/non-human: PC-based calendar/contact manager (e. g. MS Outlook) September 15, 2016 SE 430: Lecture 2 70 of 98
Build a glossary as you go § Glossary is the repository for any terms used to describe the system. § Includes items identified in the System Context Description as well as any terms encountered in interfaces to the system. § Include only terms that are unique or the definitions of which differ from their general use. § Will evolve into the standard reference for abstractions. § Benefits: Ø Establishes a common and consistent vocabulary among all stakeholders Ø Provides global view which may lead to discovering commonalties and simplification. Ø Allows browsing which promotes reuse. September 15, 2016 SE 430: Lecture 2 71 of 98
Identify functional requirements § Features vs. functional requirements: Ø Ø Ø A feature may have behavior or it may not, e. g. ‘Use a color display’ or ‘support non-Latin character sets. ’ A functional requirement has behavior, e. g. ‘Sound alarm n minutes before appointment. ’ Functional requirements represent a subset of the feature list. § Functional requirements specify what behavior the system will exhibit, but not how the behavior will be implemented! § Some functional requirements can be identified from the system features list and the system context description. § Most functional requirements are discovered through use cases. September 15, 2016 SE 430: Lecture 2 72 of 98
Functional vs. Non-Functional § A functional requirement (FR) describes what the system needs to do. Ø Example: ‘The system shall display the current customer balance’. § A non-functional requirement (NFR) describes a constraint upon the solution space. Ø Example: reliability, portability, maintainability, usability, safety, and security. Ø Also called “quality” requirements, “ilities”, or even “systemic” requirements. Ø Emergent Properties: An NFR that is realized through the careful implementation of other requirements on which it depends. Ø Example: “The query must return its results in less than three seconds” is only realizable once the architecture and much of the system functionality has been implemented. September 15, 2016 SE 430: Lecture 2 73 of 98
Identify supplementary requirements § Supplementary requirements are those not associated with a particular functional requirement of the system. § May span several functional requirements, use cases, or none at all. § Some may be addressed by aspect-oriented programming (AOP), e. g. error handling and logging, failure recovery § More examples: Ø Ø Hardware platforms, system software, security, reliability and availability, performance, file formats. System modifiability, subsystem availability, ease of learning. Legal, regulatory, fiduciary responsibility, and liability requirements or constraints. Bold examples indicate architectural quality attributes September 15, 2016 SE 430: Lecture 2 74 of 98
Feature/requirement example § Consider the requirement to monitor all medications prescribed within the hospital network Identification: REQ 003 Name: Monitor all prescribed medications Description: Monitor all medications prescribed within the hospital network. System will not monitor prescriptions from outside the hospital network User goals: Avoid unwanted drug interactions; avoid over- or undermedicating patients Priority: Required Visibility: Visible Implementation risk: Normal September 15, 2016 SE 430: Lecture 2 75 of 98
Requirements Specification § Concept of Operations Defines the high-level system requirements from the user or domain perspective. Ø Depicts the system context in which the proposed system will operate, primary data stores, and events that the system must respond to. § Systems requirement specification Ø Primarily used for large systems with substantial non-software components § Software Requirements Specification Ø Defines what the software component of the product is expected to do, and where necessary explicitly states what it should not do. Ø Supported by the requirements definition document Ø SRS is normally written in natural language but complex or critical requirements may be more formally specified. Ø September 15, 2016 SE 430: Lecture 2 76 of 98
Requirements A Requirements document can include: § Overview statement (purpose of the project) Ø Charter § Vision statement § Scope: what is covered and what is not § Customers (who will use the product / buy the product) § Goals (support faster, cheaper, more reliable, etc. Business operations) § System functions (what the system is supposed to do) § System attributes (ease of use, fault tolerance, response time, etc. ) § Competitive analysis: who is doing something similar and what does the product do (features) § System Context: description of major processes, actors and concepts September 15, 2016 SE 430: Lecture 2 77 of 98
Requirements should: § Be measurable Ø Not “fast”, but “ 10 ms to accomplish. . . ” § Have verifiable objectives Ø Not “easy to use” § Have concrete requirements § Must be able to determine if requirement has been satisfied by the design. § Must be traceable (next time). September 15, 2016 SE 430: Lecture 2 78 of 98
Requirements document should not include: § Discussion of the language to implement § Details on how the system should work § Details on the equipment involved § Algorithms or implementation details Typical problem with many requirement statements: § Embedded design (How vs. What). § Vague § Computer industry language instead of user's language. September 15, 2016 SE 430: Lecture 2 79 of 98
Validating Requirements § Is each requirement consistent with the overall objective for the § § § § system/product? Have all requirements been specified at the proper level of abstraction? That is, do some requirements provide a level of technical detail that is inappropriate at this stage? Is the requirement really necessary or does it represent an add-on feature that may not be essential to the objective of the system? Is each requirement bounded and unambiguous? Does each requirement have attribution? That is, is a source (generally, a specific individual) noted for each requirement? Do any requirements conflict with other requirements? Is each requirement achievable in the technical environment that will house the system or product? Is each requirement testable, once implemented? Does the requirements model properly reflect the information, function and behavior of the system to be built. September 15, 2016 SE 430: Lecture 2 80 of 98
Requirements Do these requirements avoid the typical problems? Ref # Function R 1 The system must provide a log to capture all the customer transactions for the fiscal year. R 2 The system will barcode documents automatically prior to distribution. At a minimum, the codes will be used to identify to which work queue the documents should be routed within the organization when they are returned. R 3 When a workflow is initiated, the system must be able to pre-fetch the documents that are in electronic image format by document type or grouping of documents by process. R 4 The system must create an entry in the journal file whenever a letter is created R 5 If an individual double-clicks on an event in a journal, the system will display the images associated with the event. R 6 The telephone system must be able to inform callers of the anticipated wait time based on the number of calls, average duration of calls, and number of calls ahead of them. September 15, 2016 SE 430: Lecture 2 81 of 98
Business Rules September 15, 2016 SE 430: Lecture 2 82 of 98
Business Rules – dictate how a company conducts its business. Business rules are likely to apply to several or all use cases developed for a particular application. Domain Rules – facts and information on the domain. Domain rules are likely to apply to several or all use cases developed for a particular application. September 15, 2016 SE 430: Lecture 2 83 of 98
Business Rules and policy required by the “business” or other agency (IRS) § Checks must be approved by manager § Credit cards must get approval § Books are due in 14 days § Tax must be collected for all sales § 14 day wait for purchasing firearms § No cigarettes to minors September 15, 2016 SE 430: Lecture 2 84 of 98
Domain Rules § Examples: Ø Ø Ø RFID sensors have a range of X meters GPS has an accuracy of X meters UV light damages paper (shield old documents) Temperature and humidity need to remain constant Documents must be handled with cloth gloves September 15, 2016 SE 430: Lecture 2 85 of 98
Activity Diagrams September 15, 2016 SE 430: Lecture 2 86 of 98
Description § Activity diagrams are an updated version of flowcharts § Use activity diagrams to describe procedural activities, business processes, and work flow Ø Useful to document current ways a business works § Activity diagrams can show different actors through the use of partitions § Essential elements: initial node, activity/action, flow/edge, fork and join, send/accept signal, object, decision/merge, partition, activity final September 15, 2016 SE 430: Lecture 2 87 of 98
Activity diagram September 15, 2016 SE 430: Lecture 2 88 of 98
Agile Perspective September 15, 2016 SE 430: Lecture 2 89 of 98
Requirements in agile § Requirements in agile are under the least methodological constraint among all SDLC methodologies § Agile views requirements as evolving throughout the system development project § This evolution is driven by the business value of the requirements to the customer; this means: Ø Established requirements may change Ø New requirements may emerge, often driven by market changes Ø Established requirements may become redundant or irrelevant September 15, 2016 SE 430: Lecture 2 90 of 98
Requirements focus: product vision § The product vision (also known as the ‘elevator statement’) defines the business § needs and objectives that the project intends to accomplish. A suggested agile product vision statement format: Ø Ø Ø For (target customer) Who (statement of the need or opportunity) The (product name) is a (product category) That (key benefit, compelling reason to buy) Unlike (primary competitive alternative) Our product (statement of primary differentiation) § Keep the product vision short and concise—‘laser-sharp’—it should be easy to remember so it can be used readily to maintain focus Adapted from: Making Sense of Agile Project Management, Charles Cobb, Wiley, 2011 September 15, 2016 SE 430: Lecture 2 91 of 98
Requirements focus: product vision ‣ Product vision example: Ø For the customer who needs to quickly diagnose minor problems with their software, the DTApp is a diagnostic tool that provides a quick check for common software problems. Unlike a call to customer support, the DTApp allows the customer to resolve common problems quickly and efficiently. September 15, 2016 SE 430: Lecture 2 92 of 98
Documenting features and requirements § Use cases are traditionally used for documenting features and § § § requirements. We will discuss them in the next lecture. In agile development we call them user stories and they are somewhat different: User stories are the most effective tool for documenting features and requirements User stories are brief, high-level, informal descriptions of what people do, or want to do Consider user stories as the ‘Post-It®’ notes for establishing requirements The analyst or developer needs to perform analysis on collected user stories in order to classify each as a need, a feature, or a requirement Ø Features require additional refinement (decomposition) to the requirements level before they can be realized in a system implementation September 15, 2016 SE 430: Lecture 2 93 of 98
Documenting features and requirements § For each identified feature, provide: Ø User story in the form: As a <role>, I do/want/need <something> so that <result/benefit> Ø Or, more simply: As a <role>, I do/want/can <something> Ø Example: As a consultant, I need a mobile diagnostic application so that I can pinpoint customer problems while at the customer site § User stories for requirements follow the same format, but are more specific: Ø Example: As a consultant, I want the mobile diagnostic application to allow me to access the company’s internal software issues database for all of our supported applications September 15, 2016 SE 430: Lecture 2 94 of 98
Requirements repository: product backlog § The product (features) backlog is the repository of all high-level product features, prioritized by business value Ø The product backlog is owned by the product owner Ø The backlog is assumed to be incomplete and subject to change Ø The product backlog is prioritized and re-prioritized continuously, across all releases and iterations, in response to project progress, completed work, and an evolving understanding of requirements Ø At the iteration level, the team selects as many of the highestpriority items from the product backlog as the team feels can be completed within the fixed time box of the iteration—this is the iteration backlog Ø This is the only point in the agile SDLC at which a backlog is locked: no changes to the iteration backlog are allowed during the iteration September 15, 2016 SE 430: Lecture 2 95 of 98
Requirements in time: product roadmap § The product roadmap decomposes the product vision into releases, each with a working set of features Ø Each release defines a subset of the overall functionality of the product Ø The product roadmap maps the features of overall functionality contained in the product backlog onto the release structure Ø The roadmap includes estimated dates, but makes no schedule commitments September 15, 2016 SE 430: Lecture 2 96 of 98
Summary § Requirements Analysis starts with the Ø Ø Problem Statement or Project Charter or Vision Requirements Document » Formal list of what the product will do Business Rules Competitive analysis § A set of well thought-out and complete requirements is needed to do a good job with the rest of analysis and design. § The major cause of problems in a project can be traced to incomplete, misleading or incorrect requirements. § We have a course in Requirements Analysis. September 15, 2016 SE 430: Lecture 2 97 of 98
Next Class Topic: Use Cases Reading: Arlow & Neustadt: Ch’s 4 & 5 Articles on the Class Page Assignment 1 – The Museum Automation Project Ø Ø Develop project description and requirements document for the Visitor Information Subsystem Due September 22, 2016. September 15, 2016 SE 430: Lecture 2 98 of 98
- Slides: 98