1. Requirement Analysis Edwin Gendron CEN 4020 Software Engineering 1

2. Process of Capturing Requirements Requirements analysis is the process of determining user expectations for a new or modified project In software engineering the requirements are often referred to as functional specifications Communication with system users is crucial to avoid ambiguity in the requirements 2

3. Steps of Capturing Requirements 3

4. Users Vs. Developers 4

5. Users Don’t understand what they want Communication is slow Technically unsophisticated Don’t understand the development process Don’t know about present technology Insist on new requirements after the cost and schedule have been fixed 5

6. Developers A natural inclination towards writing code can lead to implementation beginning before the requirements analysis is finished Different vocabs can lead to tech personnel and end-users believing they are in perfect agreement when that may not be the case May try to make the requirements fit an existing system rather than cater to the needs of the client 6

7. Sources of Requirements It’s important to identify all stakeholders and take into account all of their needs while ensuring they understand the implications of the new systems Analysts use the development of user scenarios, the identification of use cases, workplace observation, ethnography, interviews, and focus groups to create requirement lists 7

8. Modeling Notation Example: Use Case 8 A use case is a list of actions or event steps typically defining the interaction between a role and a system, to achieve a goal

9. Sources of Requirements Arrow A shows knowledge that is not made explicit by the analysts but is held by the developers B shows the analysts knowledge that was not directly stated by the stakeholders C represents the knowledge of the stakeholders that is never explicitly represented to others 9

10. Requirement Documentation The description of what a particular software does Comes in a variety of styles, notations and formality (statements in a natural language, drawn figures, detailed mathematical formulas etc.) The need for requirement documentation is typically related to the complexity of the project, the more complex the more documentation needed 10

11. Requirement Documentation Cont. A traditional way of documenting requirements is to use contract style requirement lists (alternative is Agile software development) 11 Strengths Provides a checklist of requirements Provides a contract between the project sponsor and the developers Can provide a high-level description from which low- level requirements can be derived Weaknesses Not reader friendly Doesn’t guarantee completeness Can create a false sense of mutual understanding Almost impossible to uncover all the functional requirements before the development process begins

12. Causes of Failed Projects Accepting a forced schedule or mandated completion without substantial data and analysis Adding excessive personnel to achieve unrealistic schedule compression Failing to account and adjust for requirements, growth or change and making adjustments to schedule and budget forecasts Emotional or “intuition-based” stakeholder negotiation that ignores facts and statistics Switching development methodologies to try to transform your development operation 12

13. Bug Costs at Different Stages of Development 13

14. Types of Requirements Customer: statements of assumptions and facts that define the mission objectives, environment, constraints, and measures of effectiveness and suitability Architectural: identifies the necessary architecture Structural: identifies the necessary structure Behavioral: identifies the necessary behavior Functional: identifies the necessary task, action or activity that must be accomplished 14

15. Types of Requirements Cont. Non-Functional: specifies criteria that can be used to judge the operation of a system Core Functionality: if core functionality requirements are not fulfilled the product cannot be useful Ancillary Functionality: supportive to core functionality, the product can continue to work but may have side effects(i.e. security, safety, and user friendliness) 15

16. Types of Requirements Cont. Performance: the extent to which a mission or function must be executed; generally measured in quantity, quality, coverage, timeliness or readiness Design: technical data packages and technical manuals expressing “build to”, “code to”, “buy to”, and “how to execute” requirements Derived: implied or transformed from higher- level requirements(i.e. the need for high speed) Allocated: established by dividing a high-level requirement into multiple low-level requirements 16

17. Characteristics of Requirements Correct Unambiguous Complete Consistent Ranked for importance and/or stability Verifiable Modifiable Traceable (origin is clear) 17

18. 18

19. Modeling Notations Its important to have standard notations for modeling Modeling helps us understand the requirements thoroughly Holes in the model reveal unknown or ambiguous behavior Multiple, conflicting outputs to the same input reveal inconsistencies in the requirements 19

20. Modeling Notation: Entity Relationship Diagram Entity: rectangle that represents a collection of real world objects Relationship: edge between two entities Attribute: annotation on an entity that describes data properties 20

21. Modeling Notation: Event Traces and Message Sequence Charts Event traces are a graphical description of a sequence of events that are exchanged between real-world entities 21 Message Sequence Chart

22. Modeling Notation: State Machines A graphical representation of all dialog between the system and its environment Node (state) represents a stable set of conditions that exist between events Edge (transition) represents a change in behavior due to the occurrence of an event 22

23. Modeling Notation: Petri Nets A form or state-transition notation that is used to model concurrent activities and the interaction Circles: activities or conditions Bars: transitions Arcs: connects a transition with its input/output places. Can be assigned weights. Tokens: act as enabling conditions for transitions 23

24. Modeling Notation: Data-Flow Diagrams DFD’s model functionality and the flow of data from one function to another Data store: a formal database of information Rectangles: entities that provide input data or receive the output results Bubble: a process Arrow: data flow 24

25. Formal Methods Mathematically based specification and design techniques Model requirements or software behavior as a collection of mathematical functions or relations - Functions specify the state of the system’s execution and output - A relation is used whenever an input value maps more than one output value 25

26. Modeling Notation: Decision Table A tabular representation of a functional specification that maps events and conditions to appropriate responses or actions n input conditions = 2 n possible combination of input conditions 26

27. Modeling Notation: Parnas Tables Tabular representation of mathematical functions or relations - Internal table entries store possible function results - “X” = invalid under specified conditions 27

28. Modeling Notations: Logic Consists of a language for expressing properties and a set of inference rules for deriving new, consequent properties from the stated properties In logic, a property specification represents only those values of the property's variables for which the property's expression evaluates to true First-order logic: A collection of formal systems or well- defined systems of abstract thought based on the model of mathematics Temporal logic: introduces additional logical connectives for constraining how variables can change values over time 28

29. Modeling Notations: Object Constraint Languages A language that is both mathematically precise and easy for non-mathematicians to read, write, and understand Designed for expressing constrains on object models, and expressing queries on object type 29

30. Modeling Notations: Z A leading model-based formal specification language - structures set-theoretic definitions of variables into a complete abstract-data-type model of problem - uses logic to express the pre and post conditions for each operation Method of abstractions are used to decompose a specification into manageable sized modules, called schemas 30

31. Prototyping Requirements Throwaway Prototyping: A product that will eventually be discarded rather than become part of the final software. Evolutionary Prototyping: Build a very robust prototype in a structured manner and constantly refine it. Incremental Prototyping: The final product is built as separate prototypes and merged into the design at the end. Extreme Prototyping: Used for web development. First phase consists of mainly html pages. Second a fully functional UI is developed focusing on the services requested in the contract. Third the services are implemented. 31

32. Documenting Requirements The Software Requirements Specification (SRS) is a communication tool between stakeholders and developers and plays a crucial role The SRS lays out functional and non-functional requirements that describe user interactions that the software must provide SRS establishes the basis for an agreement between customer and contractors on what the software product is to do 32

33. Software Requirements Specification IEEE 830 The specific goals of the SRS are: Facilitating reviews Describing the scope of work Providing a reference to software designers(i.e. navigation aids, document structure) Providing a framework for testing primary and secondary use cases Linking features to customer requirements Providing a platform for ongoing refinement 33

34. SRS Organized by Objects 1.Introduction to the Document 1.1 Purpose of the Product 1.2 Scope of the Product 1.3 Acronyms, Abbreviations, Definitions 1.4 References 1.5 Outline of the rest of the SRS 2.General Description of Product 2.1 Context of Product 2.2 Product Functions 2.3 User Characteristics 2.4 Constraints 2.5 Assumptions and Dependencies 34 3.Specific Requirements 3.1 External Interface Requirements 3.1.1 User Interfaces 3.1.2 Hardware Interfaces 3.1.3 Software Interfaces 3.1.4 Communications Interfaces 3.2 Functional Requirements 3.2.1 Class 1 3.2.2 Class 2 … 3.3 Performance Requirements 3.4 Design Constraints 3.5 Quality Requirements 3.6 Other Requirements 4.Appendices

35. Participants in the Requirement Process Stakeholders: A person, group or user that has an investment, share, or interest in the software being built Engineers/Developers: The people responsible for building the software that reflects the clients needs Business/System Analysis Specialists: Attempt to solve communication problems between the stakeholder and developer 35

36. Validation and Verification V & V is the process of checking that a software system meets specifications and that it fulfills its intended purpose (software quality control) Verification = Are we building the product right? Validation = Are we building the right product? Achieved by dynamic testing and other forms of review Reviews may be used early in the life cycle to provide for software validation 36

37. Measuring Requirements The best practice is to take the composed list of requirements merely as clues and repeatedly ask “why?” until the actual business purposes are discovered Stakeholders and developers can then devise tests to measure what level of each goal has been achieved Once a small set of measured goals has been established, short iterative development phases may proceed 37

38. Specification Language A formal language in computer science used during systems analysis, requirements analysis, and systems design to describe a system at a much higher level than a programming language, which is used to produce executable code for a system Generally not executed, specification languages are meant to describe the what, not the how 38

39. Specification Language: UML Unified Modeling Language (UML) combines multiple notation paradigms Eight graphical modeling notations including - Use-case diagram (high-level data flow diagram) - Class diagram (entity-relationship model) - Sequence diagram (event trace) - Collaboration diagram (event trace) - Statechart diagram (state-machine model) - OCL properties (logic) 39

40. UML Class Diagram Example 40

41. UML Statechart Diagram Example 41

42. References https://en.wikipedia.org/wiki/Requirements_analysis http://searchsoftwarequality.techtarget.com/definition/requirements- analysishttp://searchsoftwarequality.techtarget.com/definition/requirements- analysis https://lh5.googleusercontent.com/- 5bhHiCfucB8/UXfFFstDPvI/AAAAAAAAA3M/NmQi5zhTcno/w800- h800/How-users-see-programmers-and-how-programmers-see- users.jpg (user/developer pic)https://lh5.googleusercontent.com/- 5bhHiCfucB8/UXfFFstDPvI/AAAAAAAAA3M/NmQi5zhTcno/w800- h800/How-users-see-programmers-and-how-programmers-see- users.jpg http://www.umsl.edu/~kjs976/RequirementTacit.html https://en.wikipedia.org/wiki/Software_documentation#Requirements _documentationhttps://en.wikipedia.org/wiki/Software_documentation#Requirements _documentation http://www.infoq.com/articles/software-failure-reasons http://i.stack.imgur.com/8TcYd.png (bug costs chart)http://i.stack.imgur.com/8TcYd.png http://www.cavdar.net/2011/10/10/characteristics-of-a-good- software-requirements-specification-srs/http://www.cavdar.net/2011/10/10/characteristics-of-a-good- software-requirements-specification-srs/ 42

43. References https://en.wikipedia.org/wiki/Software_prototyping https://en.wikipedia.org/wiki/Software_requirements_specification https://en.wikipedia.org/wiki/Software_verification_and_validation http://www.math- cs.gordon.edu/courses/cs211/ATMExample/UseCases.gif (use case ex)http://www.math- cs.gordon.edu/courses/cs211/ATMExample/UseCases.gif https://en.wikipedia.org/wiki/Use_case https://en.wikipedia.org/wiki/Specification_language https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd =1&cad=rja&uact=8&ved=0ahUKEwiyuLz_y- 3KAhUHt4MKHW__AB0QFggcMAA&url=http%3A%2F%2Fwww.cs. ucf.edu%2F~turgut%2FCOURSES%2FPfleeger- Atlee4EClassMaterials%2FPA- chapter04.ppt&usg=AFQjCNFmDWv_Z3- 3T3nYFdY3F4bDPUBkfw&sig2=q35AabkIvgcWKBGxACObCg&bv m=bv.113943665,d.amc 43