4.1. Since a focus on quality demands resources and time, is it possible to be agile and still maintaining quality focus? Whether the process model you choose is prescriptive or agile, the basic tenets of agile development should govern your approach. Every aspect of the work you do should emphasize economy of action keep your technical approach as simple as possible, keep the work products you produce as concise as possible, and make decisions locally whenever possible. The exit condition for every process activity, action, and task should focus on the quality of the work product that has been produced.
4.3. Describe the concept of separation of concerns in your own words' Divide and conquer stated in a more technical manner, analysis and design should always emphasize separation of concerns (soc). A large problem is easier to solve if it is subdivided into a collection of elements (or concerns). Ideally, each concern delivers distinct functionality that can be developed, and in some cases validated, independently of other concerns. 4.8. Do some research on facilitation" for the communication activity ( use the references provided or others)and prepare a set of guidelines that focus solely on facilitation' Someone should facilitate the activity. Every communication meeting should have a leader (a facilitator) (1) to keep the conversation moving in a productive direction,( 2) to media teany conflict that does occur, and (3) to ensure than other principles are followed'
4.7. Why is it necessary to "move on"? (a) Once you agree to something, move on. (b) If you can't agree to something, move on. (c) If a feature or function is unclean and cannot be clarified at the moment, move on, communication, like any software engineering activity, takes time. Rather than iterating endlessly, the people who participate should recognize that many topics require discussion and that "moving on" is sometimes the best way to Achieve communication agility.
4.9. Describe what granularity means in the context of a project schedule? Granularity refers to the level of detail that is introduced as a project plan is developed. A "highgranularity/'plan provides significant work task detail that is planned over relatively short time increments (so that tracking and control occur frequently). A "low-granularity" plan provides broader work tasks that are planned over longer time periods. In general, granularity moves from high to low as the project time line moves away from the current date. Over the next few weeks or months, the project can be planned in significant detail. Activities that won't occur for many months do not require high granularity (too much can change).
4.11. What three domains are considered during requirements modeling? Requirements models (also called analysis models) represent customer requirements by depicting the software in three different domains: 1. The information domain. 2. The functional domain. 3. The behavioral domain. Design models represent characteristics of the software that help practitioners to construct it effectively: the architecture, the user interface, and component-level detail.
4.13. What is a successful test? A successful test is one that uncovers an as-yet-undiscovered error. A successful test is one in which no errors are found. Your objective is to design tests that systematically uncover different classes of errors and to do so with a minimum amount of time and effort. If testing is conducted successfully (according to the objectives stated previously),it will uncover errors in the software. . 4.15. Why is feedback important to the software team? Every model should be reviewed by members of the software team. The intent of these reviews is to provide feedback that can be used to correct modeling mistakes, change misinterpretations, and add features or functions that were inadvertently omitted.
5.2. You have been given the responsibility to elicit requirements from a customer who tells you he is too busy to meet with you. What should you do?
5.4. Why do we say that the requirements model represents a snapshot of a system in time?
The intent of the analysis model is to provide a description of the required in formational, functional, and behavior a domains for a computer-based system. The model changes dynamically you learn more about the system to be built, and others take holders understanding more about what they really require. For that reason, the analysis model is a snapshot of requirements at any given time
5.6. Develop at least three additional "context-free questions" that you might ask a stakeholder during inception.
Stakeholders from the business community (e.g., business managers, marketing people, product managers) define a business case for the idea, try to identify the breadth and depth of the market, do a rough feasibility analysis, and identify a working description of the project scope.
5.8. Your instructor will divide the class into groups of four to six students. Half of the group will play the role of the marketing department, and half will take on the role of software Engineering. Your job is to define requirements for the Safe Home security function described in this chapter. Conduct a requirements gathering meeting using the guidelines presented in this chapter.
5.9. Develop a complete use case for one of the following activities: a. Making a withdrawal at an ATM b. Using your charge card for a meal at a restaurant c. Buying a stock using an online brokerage account d. Searching for books (on a specific topic) using an on-line bookstore e. An activity specified by your instructor'
5.10. What do use case "exceptions" represent?
5.12. Using the template presented in section5,5.2, suggest one or more analysis pattern for the following application domains: a. Accounting software b. E-mai1 software c. Internet browsers d. Word-Processing software e. Website creation software f. An application domain specified by your instructor
5.14. What do you think happens when requirement validation uncovers an error? who is involved in correcting the error? The work products produced as a consequence of requirements engineering are assessed for quality during a validation step. Requirements validation examines the specifications to ensure that all software requirements have been stated unambiguously at inconsistence, missions, and errors have been detected and corrected; and that the work products conform to the standards established for the process the project, and the product.
The primary requirements validation mechanism is the technical review. The review team that validates requirements includes software engineers, customers, users, and other stakeholders who examine the specification looking for errors in content or interpretation, areas where clarification may be required, missing information, inconsistencies (a major problem when large products or systems are engineered), conflicting requirements, or unrealistic (unachievable) requirements.
