1 / 57

SOFTWARE ANALYSIS AND DESIGN I

SOFTWARE ANALYSIS AND DESIGN I. 12/10/07 Vít STINKA. LESSON AGENDA. Requirements management Visual modeling Analysis & Design Requirements traps. MOTIVATION. REQUIREMENTS MANAGEMENT. SYSTEM REQUIREMENTS CAPTURE. Requirement

fiona
Télécharger la présentation

SOFTWARE ANALYSIS AND DESIGN I

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. SOFTWAREANALYSIS AND DESIGN I 12/10/07 Vít STINKA

  2. LESSON AGENDA • Requirements management • Visual modeling • Analysis & Design • Requirements traps

  3. MOTIVATION

  4. REQUIREMENTS MANAGEMENT

  5. SYSTEM REQUIREMENTS CAPTURE Requirement A feature that the system must have or a constraint that it must satisfy to be accepted by the customer Requirements capture (elicitation, ...) The specification of the system in a way that the customer/user understands • Requires the collaboration ofseveral groups of participants with different backgrounds GAP CHALLENGE:How to bridge the gap?

  6. TYPES OF REQUIREMENTS: FURPS+ Functionality Usability Reliability Performance Supportability + Technological constraints

  7. FUNCTIONALITY Functionality the system must by able to perform Functionality description - inputs, outputs, transformations, interaction Usually Use Case model Other requirements - „non-functional“

  8. USABILITY Ergonomy, requirements about usability Aesthetics User interface consistency Help, on-line help, context sensitive help Wizards and smart-guides User manual(s) Course materials

  9. RELIABILITY Frequency and severity of failure Recoverability Predictability for. example free hard drive space Accuracy Mean time between failure (MTBF) Security

  10. PERFORMANCE Number of concurrent users Speed Efficiency Availability Throughput Response time Recovery time Resource usage

  11. SUPPORTABILITY Testability Extensibility Adaptability Maintainability Compatibility Configurability Serviceability Installability Localizability (internationalization)

  12. + TECHNOLOGICAL CONSTRAINTS Design constraints Modeling tools, standards... Implementation constraints Standards Programming languages Database integrity policies Resource limits Operation environments Interface requirements External systems Formats, timings... Physical requirements Material, shape, size, weight... Like physical network configurations

  13. SRS The Software Requirements Specification (SRS) captures the complete software requirements for the system, or a portion of the system. When using use-case modeling, this artifact consists of Package(s) containing use cases of the use-case model Applicable Supplementary Specifications. As soon as possible...

  14. SYSTEM REQUIREMENTS CAPTURE • System requirements capture constructs two main models: • Domain model: describes the application’s static data requirements • Use-case model: describes the application’s dynamic processing requirements • The domain model and use-case model are developed over several development increments • Inception phase: identify most domain model elements and use cases in order to delimit the system and scope the project (detail the most critical use cases (less than 10%)) • Elaboration phase: capture most (80%) of the remaining requirements • Construction phase: capture remaining requirements and implement the system • Transition phase: no requirements capture unless there are changing requirements

  15. REQUIREMENTS - THE LEVEL OF ABSTRACTION

  16. WHAT IS HARD ABOUT REQUIREMENTS MANAGEMENT? Requirements are not always obvious, and can come from many sources Requirements are not always easy to express clearly in words There are many different types of requirements at different levels of detail The number of requirements can become unmanageable if not controlled Requirements are related to one another and also to other deliverables of the software engineering process Requirements have unique properties or property values. For example, they are neither equally important nor equally easy to meet There are many interested parties, which means requirements need to be managed by cross-functional groups of people Requirements change

  17. IMPORTANCE OF REQUIREMENTS CAPTURE Reasons for failure of/problems with software development: • Incomplete requirements 13.1% • Lack of user involvement 12.4% • Lack of resources 10.6% • Unrealistic expectations 9.9% • Lack of executive support 9.3% • Changing requirements and specifications 8.7% • Lack of planning 8.1% • System no longer needed 7.5% • Requirements capture involved in most cases

  18. 100 60-100 10.00 10 3.00 1.50 1.00 0.75 1 Reqmts Design Code Test System test Field use IMPORTANCE OF REQUIREMENTS CAPTURE cost to find and fix a defect log scale • BUT, requirements capture is VERY DIFFICULT!

  19. Find Classes and Associations Detail Classes and Associations Find Actors and Use Cases Structure the Use-Case Model Prototype User-Interface Detail Use Cases Prioritize Use Cases User-Interface Designer Architect Use-Case Specifier Domain Analyst System Analyst SYSTEM REQUIREMENTS CAPTURE PROCESS

  20. FOUR VARIABLES • Quality, quantity, time & budget are requirements • Consider these variables when planning phases

  21. VISUAL MODELING

  22. ARCHITECTING A DOG HOUSE Can be built by one person Requires Minimal modeling Simple process Simple tools

  23. ARCHITECTING A HOUSE Built most efficiently and timely by a team Requires Modeling Well-defined process Power tools

  24. WE WANT TO ARCHITECT A HIGH RISE... :)

  25. MODELING A HOUSE

  26. A technique for information sharing and presentation using pictures Supports communication „A single picture can sometimes tell more than several pages of text“ Business processes Context of the system Organization and/or behavior of code System‘s deployment There is a need of standard, well understood common language VISUAL MODELING

  27. Better problem understanding Better communication User-to-developer Developer-to-developer Team-to-management Easy to find some kind of errors Simulation Code generation Managing the complexity Model - the abstraction of reality ADVANTAGES OF VISUAL MODELING

  28. De Facto standard for visual modeling and object-oriented analysis and design Managed by OMG (Object Management Group, www.omg.org) UML is a language for Visualization Specification Construction Documentation UNIFIED MODELING LANGUAGE

  29. Functional modeling Structured analysis&design Data flow diagrams Flow charts Data modeling Entity relationships Focus on behavior only or data only Sensitivity to requirements changes All parts are mutually connected (CRUD matrix for example) Maintanance problems FORMER METHODS

  30. HP Fusion Meyer Booch Operation descriptions and message numbering Before and after conditions Booch method Rumbaugh Embley Harel OMT Singleton classes and high-level view Statecharts Gamma, et al Wirfs-Brock Frameworks and patterns Responsibilities Odell Shlaer - Mellor Jacobson Classification Object lifecycles OOSE EVOLUTION OF THE UML

  31. Notation - a visual language Similar to music notes or electrotechnical schemas Describes how to express the information, not how to manage the work or find the information Process - a methodology Telĺs how to work Defines the organization of roles, artifacts and activities For system‘s definition you won‘t use only one picture NOTATION AND PROCESS

  32. Class Diagrams ObjectDiagrams SequenceDiagrams ComponentDiagrams CollaborationDiagrams DeploymentDiagrams Statecharts UMLDIAGRAMS Use Case Diagrams Model ActivityDiagrams

  33. WHAT UML IS NOT? • Not textual • Not fixed • Not a process • No guarantee for succes

  34. PRINCIPLES OF MODELING • The choice of what models to create has a profound influence on how a problem is attacked and how a solution is shaped • Every model may be expressed at different levels of precision • The best models are connected to reality • No single model is sufficient. Every nontrivial system is best approached through a small set of nearly independent models Booch, Jacobson, Rumbaugh

  35. REQUIREMENTS TRAPS

  36. TRAP 1: CONFUSION OVER “REQUIREMENTS” Symptoms • Stakeholders discuss “requirements” withno adjectives in front • Project sponsor presents a high-levelconcept as “the requirements” • User interface screens are viewed as“the requirements” • User provides “requirements,” butdevelopers still don’t know what to build • Requirements focus just on features and functionality

  37. #1: Business Requirements Vision and Scope Document #2: User Requirements Quality Attributes Use Case Document Other Nonfunctional Requirements System Requirements BusinessRules #3:Functional Requirements Constraints Software Requirements Specification THREE LEVELS OF SOFTWARE REQUIREMENTS

  38. TRAP 2: INADEQUATE CUSTOMER INVOLVEMENT Symptoms • Some user classes are overlooked • Some user classes don’t have a voice • User surrogates attempt to speak for users • User managers • Marketing • Developers • Developers have to make many requirements decisions • Customers reject the product when they first see it

  39. ProcuringCustomer RequirementsAnalyst Product Champion Customer Manager System Architect Help Desk Marketing USER-DEVELOPER COMMUNICATION PATHS Developer User

  40. TRAP 3: VAGUE & AMBIGUOUS REQUIREMENTS Symptoms • Readers interpret a requirement in severaldifferent ways • Requirements are missing information thedeveloper needs • Requirements are not verifiable • Developer has to ask many questions • Developer has to guess a lot

  41. TRAP 3: VAGUE & AMBIGUOUS REQUIREMENTS Solutions • Formally inspect requirement documents • Write conceptual test cases against requirements • Model requirements to find knowledge gaps • Use prototypes to make requirements more tangible • Define terms in a glossary • Avoid ambiguous words: • minimize, maximize, optimize, rapid, user-friendly, simple, intuitive, robust, state-of-the-art, improved, efficient, flexible, several, and/or, etc., include, support...

  42. 100% 80% 60% 40% 20% 0% L M H TRAP 4: UNPRIORITIZED REQUIREMENTS Symptoms • All requirements are critical! • Different stakeholders interpret “high”priority differently • After prioritization, 95% are still high • Developers don’t want to admitthey can’t do it all • It’s not clear which requirementsto defer during the “rapid descoping phase.”

  43. cost value REQUIREMENTS PRIORITIZATION • Need to understand which requirements are most important and most urgent • Not everything can be top priority! • Setting priorities will help you • Work on the right things first • Make tradeoff decisions • Deal with added and changed requirements • Need to bypass politics and emotion • Prioritize early and continuously • Develop priorities collaboratively

  44. TRAP 5: BUILDING FUNCTIONALITY NO ONE USES Symptoms • Users demand certain features, then no one uses them • Proposed functionality isn’t related to business tasks • Developers add functions because “the users will love this” • Customers don’t distinguish “chrome” from “steel”

  45. TRAP 5: BUILDING FUNCTIONALITY NO ONE USES Solutions • Derive functional requirements from use cases • Trace every functional requirement back to its origin • Identify user classes who will benefit from each feature • Analytically prioritize requirements, use cases, or features • Have customers rate value (benefit and penalty) • Have developers estimate cost and risk • Avoid requirements with high cost and low value

  46. TRAP 6: ANALYSIS PARALYSIS Symptoms • Requirements development seems to go on forever • New versions of the SRS are continually released • Requirements are never baselined • All requirements are modeled six ways from Sunday • Design and coding can’t start until the SRS is perfect

  47. TRAP 6: ANALYSIS PARALYSIS Solutions • Remember: the product is software, not an SRS • Select an appropriate development life cycle • Staged release, evolutionary prototyping, time-boxing • Decide when requirements are good enough • Acceptable risk of proceeding with construction • Reviewed by analyst, developers, testers, and customers • Model just the complex or uncertain parts of the system • Don’t include final user interface designs in SRS

  48. TRAP 7: SCOPE CREEP Symptoms • New requirements are continually added • Schedule doesn’t change • No more resources provided • Product scope is never clearly defined • Requirement changes sneak in through the back door • Proposed requirements come, and go, and come back • Scope issues are debated during SRS reviews • Sign-off is just a game

  49. TRAP 7: SCOPE CREEP Solutions • Determine root causes of the scope creep • Document the product’s vision and scope • Define system boundaries and interfaces • Follow the change control process for all changes • Improve requirements elicitation methods • Follow a meaningful baselining process • Renegotiate commitments when requirements change

  50. TRAP 8: INADEQUATE CHANGE PROCESS Symptoms • No change process is defined • Some people bypass the change process • Talk to buddies on the inside • Implement rejected changes • Work is done on proposed changes before they’re approved • New functionality becomes evident during testing • Unclear change request status • Changes aren’t communicated to all those affected • It’s not clear who makes change decisions

More Related