1 / 44

Software Requirements Engineering

Software Requirements Engineering. Types of Requirements IEEE Std 830 – 1998 http://ieeexplore.ieee.org/xpl/standardstoc.jsp?isnumber=15571&isYear=1998 Defines the following kinds of requirements: Functional External interfaces Performance Logical database

Download Presentation

Software Requirements Engineering

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. Software Requirements Engineering

  2. Types of Requirements • IEEE Std 830 – 1998 http://ieeexplore.ieee.org/xpl/standardstoc.jsp?isnumber=15571&isYear=1998 • Defines the following kinds of requirements: • Functional • External interfaces • Performance • Logical database • Design constraints: standards compliance; software systems attributes • Software system attributes: reliability; availability; security; maintainability; portability

  3. External Interfaces

  4. Requirements Specification for Real-Time Systems Specification methods: formal, informal, semiformal

  5. Formal Methods in Software Specification • There are three general uses for formal methods: • Consistency checking • Model Checking • Theorem Proving • Formal methods also provide opportunities for reusing. • Example from the nuclear monitoring system: • 1.1. If interrupt A occurs then task B stops executing • 1.2. Task A begins executing upon arrival of interrupt A • 1.3. Either task A is executing and task B is not, or task B is executing and task A is not, or both are not executing p – interrupt A arrives; q – task B is executing; r – task A is executing

  6. Finite State Machine

  7. Finite State Machine

  8. Mealy Automaton

  9. Statecharts

  10. Statecharts Chain reaction: Orthogonal states: if state Y consists of and components A and D, Y is called an orthogonal product of A and D. If Y is entered from outside, both states A and D are entered simultaneously. Communication between the and states can be achieved via global memory, whereas synchronization can be achieved through broadcast communication. Broadcast communication is depicted by the transition of orthogonal states based on the same event. Broadcast communication can describe a chain reaction.

  11. Petri Nets

  12. Petri Nets

  13. Petri Nets

  14. Requirements Analysis with Petri Nets They can be used for race condition and deadlock identification

  15. Structured Analysis and Design

  16. Structured Analysis and Design

  17. Object-Oriented Analysis and the Unified Modeling Language

  18. UML Class Diagrams

  19. Requirements Document

  20. Software Requirements Organization

  21. Requirements to Software Requirements • Correct • Unambiguous (not subject to different interpretations) • Complete • Consistent (no contradicting requirements) • Ranked for importance • Verifiable • Modifiable (information hiding) • Traceable

  22. Language Issues

  23. Requirements Validation

  24. Software System Design • Software Properties • Reliability • 1.1. r(t) – probability that time T of failure is greater than t: 1.2. Failure function 1.3. Mean time to first failure (MTFF) and Mean time between failures (MTBF)

  25. Software Properties 2. Correctness (close to reliability) 3. Performance 4. Usability 5. Interoperabililty (ability of coexist and cooperate with other systems. Can be measured in terms of compliance with open system standards) 6. Maintainability - a system in which changes are are easy to implement 6.1. Evolvability (how easy to incorporate new) 6.2. Repairability (how easy to fix bugs) 7. Portability 8. Verifiability

  26. Basic Software Engineering Principles • Rigor and Formality – use mathematical and algorithmic descriptions • Separation of Concerns – Divide-and-Conquer • Modularity

  27. Cohesion and Coupling

  28. Basic Software Engineering Principles 4. Anticipation of Change 5. Generality 6. Incrementality – increment provides additional functionality, brings the product closer to the final one 7. Traceability – a high level of traceability ensures that the software requirements flow down through the design and code and then can be traced back up at every stage of the process. Traceability can be obtained by providing links between all documentation and the software code

  29. The Design Activity

  30. Procedural-Oriented Design Top-down or bottom-up approaches. Parnas partitioning uses principle of information hiding. A list of difficult decisions of things which are likely to change is prepared. Modules are then designated to hide the eventual implementation of of each design decision or feature from the rest of the system. Thus, only the function of the module is visible to other modules, not the method of implementation. Changes in these modules are not likely to affect the rest of the system.

  31. Structured Design and Analysis

  32. Structured Design and Analysis • Data Dictionary is supported: • Entry type (data flow, data store, terminator, process) • Name • Alias • Description • Found in • Real-Time Extensions of SASD • Dashed lines are used to show control flow and solid bars show “stored” control commands (control stores)

  33. Relationship between Data and Control Flow Diagrams

  34. Design in Procedural Form Using FSM

  35. Object-Oriented Design • OO languages are characterized by data abstraction, inheritance, polymorphism and messaging. • Open-Closed Principle – classes should be open to extensions but closed to modifications • Once and Only Once – any aspect of the software system should exist in only one copy • Dependency Inversion Principle – high-level modules should not depend on low-level modules

  36. OO Design Using UML

  37. UML Diagrams • Activity diagrams – close to flow charts but can model parallel activities • Class diagrams • Collaboration diagrams – show messages passed between objects • Component diagrams – are made of components, interfaces and relationships • Deployment diagrams – show real-world nodes and deployment of components in them • Object diagrams are related to class diagrams • Sequence diagrams are related to collaboration diagrams • Statechart Diagrams

  38. UML Sequence Diagrams

  39. UML Collaboration Diagrams

  40. UML Statechart Diagrams

  41. UML Activity Diagrams

  42. UML Deployment Diagrams

More Related