1. Requirement Analysis SOFTWARE ENGINEERING

2. What are Requirements? Expression of desired behavior Deals with objects or entities, the states they can be in, and the functions that are performed to change states or object characteristics Steps of Capturing Requirements

3. Forms of Requirements Functional Requirement-Describes required behavior in terms of required activities, such as reactions to inputs Quality Requirement-Describes some quality characteristic that the software solution must possess, such ease of use and high reliability Design Constraint-Design decision, such as choice of platform or interface components Process Constraint-Restriction on the techniques or resources that can be used to build the system

4. Forms of Requirements

5. How Users & Developers View Each Other Common Stereotypes

6. Sources of Requirements The Volere requirement process Model, shows sources of possible requirements

7. Requirement Documentation Two types Requirements Definition Document-aimed at a business audience, such as clients, customers, users Requirements Specification Document-aimed at a technical audience, such as designers, testers, project managers Requirements Definition-a complete listing of everything the customer wants to achieve Requirements Specification-restates the requirements as a specification of how the proposed system shall behave

8. Requirement Documentation Examples

9. Causes of Failed Projects According to Standish Group survey in 1995 from over 350 companies

10. Cost to Fix Bugs at Different Stages of Design According to Boehm and Papaccio 1988 $1-find and fix a requirements based problem during the requirements definition process $5-to repair it during design $10-during coding $20-during unit testing $200-after delivery of system

11. Characteristics of Requirements Correct-Make sure there are no errors Consistent-There are no conflicting requirements Unambiguous-Requirements has only one interpretation Complete-Everything stated in the requirement documents should be there Feasible-Solution to every customer need should exist Relevant-To user needs Testable-Every requirement stated is verifiable Traceable-The requirements organized and uniquely labeled for easy reference

12. Modeling Notations: Entity-Relationship Diagrams A popular, graphical notational paradigm for representing conceptual models Example:

13. Modeling Notations: Unified Modeling Language(UML) Class Diagrams A collection of notations used to document software specifications and designs Example:

14. Modeling Notations: Event Traces A graphical description of a sequence of events that are exchanged between real-world entities Example:

15. Modeling Notations: Message Sequence Charts An enhanced event-trace notation, with facilities for creating and destroying entities, specifying actions and timers, and composing traces Example:

16. Modeling Notations: State Machines a graphical description of all dialog between the system and its environment UML Statechart Diagrams depicts the dynamic behavior of the objects in a UML class

17. Modeling Notations: Petri Nets a form of state-transition notation that is used to model concurrent activities and their interactions Data-Flow Diagrams models functionality and the flow of data from one function to another

18. Modeling Notations: Use-Case Diagram similar to a top-level data-flow diagram that depicts observable, user-initiated functionality in terms of interactions between the system and its environment

19. Modeling Notations: Formal Methods mathematically based specification and design techniques Decision Tables a tabular representation of a functional specification that maps events and conditions to appropriate responses or actions

20. Modeling Notations: Parnas Tables tabular representations of mathematical functions or relations

21. Modeling Notations: First –Order Logic logic commonly used to express properties of software requirements Temporal Logic introduces additional logical connectives for constraining how variables can change value over time – more precisely, over multiple points in an execution

22. Modeling Notations: Object Constraint Language an attempt to create a constraint language that is both mathematically precise and is easy for non-mathematicians Z structures set-theoretic definitions of variables into a complete abstract-data-type model of a problem

23. Prototyping Requirements Throw-Away Prototype software that is developed to learn more about a problem or about a proposed solution, and that is never intended to be part of the delivered software. Evolutionary Prototype software that is developed not only to help us answer questions but also to be incorporated into the final product

24. Documenting Requirements Need documents so customers and developers can refer to it throughout development and maintenance Requirements definition is a record of the requirements expressed in the customer’s terms Requirements specification covers exactly the same ground as the requirements definition, but from the perspective of the developers

25. IEEE standard for Software Requirements Specification Provides templates for organizing the requirements specification by mode of operation, function, feature, category of user, and so on

26. Participants in the Requirement Process Clients, the ones paying for the software to be developed Customers, buy the software after it is developed Users, familiar with the current system and will use the future system Domain experts, familiar with the problem that the software must automate Market researchers, conducted surveys to determine future trends and potential customers’ needs Lawyers or auditors, familiar with government, safety, or legal requirements Software engineers or other technology experts

27. Validation and Verification In requirements validation, we check that our requirements definition accurately reflects the customer’s needs In a review, representatives from our staff and the customer’s staff examine the requirements document individually and then meet to discuss identified problems

28. Measuring Requirements Measure by 1 to 5 1 being you understand the requirements completely 5 being you do not understand the requirement at all GoodBad Measuring Requirement Readiness

29. Choosing a Specification Technique Applicability Implementability Testability Checkability Maintainability Level of expressibility Soundness Verifiability Run-time safety Tools Maturity Looseness Learning curve Technique Maturity Data Modeling Discipline

30. Sources http://www.scielo.br/img/fbpe/jbcos/v5n1/v5n1a4f349.gif http://www.cse.msu.edu/~chengb/RE-491/Papers/atlee- chapter4.pdf http://www.cse.msu.edu/~chengb/RE-491/Papers/atlee- chapter4.pdf http://rajeshg.info/book/export/html/5