<p> GCIS 504/GENG 580 Requirements Engineering (Quiz 7) Team Skill 5</p><p>Name: </p><p>1. Describe the relationship between software requirements and use cases.</p><p>2. Describe the Relationship between Features and Software Requirements.</p><p>3. Discuss the limitation of use cases</p><p>4. List three types of requirements</p><p> a. ______</p><p> b. ______</p><p> c. ______</p><p>5. You are developing an e-commerce system in which you have a base use case called Place Online Order that has an extending use case called Specify Shipping Instructions. Draw the relationship between those two use cases </p><p>6. Explain the semantic of the relationship in question 5. 7. Explain the semantic of the relationship in the following diagram.</p><p>8. Why we need a supplementary Specification?</p><p>9. Nonfunctional requirements can be organized into four categories: </p><p> a. ______</p><p> b. ______</p><p> c. ______</p><p> d. ______</p><p>10. Provide one example for each category in question 9.</p><p> a. ______</p><p> b. ______</p><p> c. ______</p><p> d. ______</p><p>11. Provide two examples of design constraint. </p><p> a. ______</p><p> b. ______</p><p>12. How to avoid both over-specified requirements and under-specified design? 13. When specifying requirements, describe the best scenario to use </p><p> a. use case: ______</p><p> b. pseudo-code:______</p><p> c. finite state machines: ______</p><p> d. decision trees: ______</p><p> e. activity diagrams: ______</p><p> f. entity-relationship models: ______</p><p>Use cases are just one way to express software requirements. Use cases can't conveniently express certain types of requirements Requirements shall tell us what the system is to do, and NOT how the system shall do it. A use case is a technique for documenting the potential requirements of a new system or software change Use cases are deceptively simple tools for describing the behavior of software or systems.</p><p>Software Req.s Detailed descriptions of system services (features). We can code from them. They should be specific enough to be "testable" </p><p>Features Simple descriptions of system services in a shorthand manner. Help us understand and communicate at a high level of abstraction. We can't fully describe the system and write code from those descriptions. They are too abstract for this purpose.</p><p>Use cases have limitations: (http://en.wikipedia.org/wiki/Use_case) . Use case flows are not well suited to easily capturing non-interaction based requirements of a system (such as algorithm or </p><p> mathematical requirements) or non-functional requirements(such as platform, performance, timing, or safety-critical aspects). These are </p><p> better specified declaratively elsewhere.</p><p>. Use cases templates do not automatically ensure clarity. Clarity depends on the skill of the writer(s).</p><p>. There is a learning curve involved in interpreting use cases correctly, for both end users and developers. As there are no fully standard </p><p> definitions of use cases, each group must gradually evolve its own interpretation. Some of the relations, such as extends, are ambiguous in </p><p> interpretation and can be difficult for stakeholders to understand.</p><p>. Proponents of Extreme Programming often consider use cases too needlessly document-centric, preferring to use the simpler approach</p><p> of a user story.</p><p>. Use case developers often find it difficult to determine the level of user interface (UI) dependency to incorporate in a use case. While </p><p> use case theory suggests that UI not be reflected in use cases, it can be awkward to abstract out this aspect of design, as it makes the use </p><p> cases difficult to visualize. Within software engineering, this difficulty is resolved by applyingrequirements traceability through the use of </p><p> a traceability matrix.</p><p>. Use cases can be over-emphasized. In Object Oriented Software Construction (2nd edition), Bertrand Meyer discusses issues such as </p><p> driving the system design too literally from use cases and using use cases to the exclusion of other potentially valuable requirements </p><p> analysis techniques.</p><p>. Use cases have received some interest as a starting point for test design.[6] Some use case literature, however, states that use case pre </p><p> and postconditions should apply to all scenarios of a use case (i.e., to all possible paths through a use case) which is limiting from a test </p><p> design standpoint. If the postconditions of a use case are so general as to be valid for all possible use case scenarios, they are likely not to be</p><p> useful as a basis for specifying expected behavior in test design. For example, the outputs and final state of a failed attempt to withdraw </p><p> cash from an ATM are not the same as a successful withdrawal: if the postconditions reflect this, they too will differ; if the postconditions </p><p> don’t reflect this, then they can’t be used to specify the expected behavior of tests. An alternate perspective on use case pre & </p><p> postconditions more suitable for test design based on model-based specification is discussed in [7]</p><p>. Usability . Reliability . Performance . Supportability </p><p> Sources of Design Constraints 1. Restriction of design options 2. Conditions imposed on the development process 3. Regulations and imposed standards. </p>