Skip to content
Textbook Guides

Solution Manual For Software Engineering: Theory And Practice, 4th Edition

Solution Manual For Software Engineering: Theory And Practice, 4th Edition helps you understand textbook content with detailed solutions and explanations for each problem.

Preview 16 of 54 pages

See the first 16 pages exactly as they appear in the document.

  1. Page 1
    Read page 1 as text

    . . Chapter 1: Why software engineering? 1. This type of situation could be indicative of a crisis in that the inadequacies of software contributed to the tragic loss of life. The fact that the pilot relied completely on the software to guide the plane turned a user interface error into a severe accident. In general, of course, aviation is better off because of software engineering because the high reliability of aviation software has made flying safer and more cost-effective. The situation that caused the accident is really a user interface problem. During development, more user feedback could have been designed into the software (so that the pilot might have been notified that he had typed in the code for Bogota, not Cali) and more usability testing could have been done (so that the misunderstanding might have surfaced before the software was installed in the airplane). The other issue is that of system boundary. Although the aeronautical charts used by pilots are outside the boundary of the computer system, the developers need to have knowledge of them and the codes and abbreviations they contain. 2. One example is the processing and synthesis of sensor data. If lots of real-time sensor data are flowing in to the software system, the hard part is getting the timing right so that an accurate picture of the overall system is obtained. For instance, if the software is controlling the shape of the wing of a plane, based on real-time sensor data about the air speed, pressure, temperature, etc., decisions must be based on up-to-date information from the sensors, even when flying through rapidly changing conditions (like a storm). The actual polling of the sensors is easy; the relationships are hard. The relationships are more complicated still when dealing with asynchronous changes to the wing shape. 3. Errors are misunderstanding that reside in the developer’s thought processes. When that misunderstanding leads the developer to write something in a development artifact (specification, design, code, test data, etc.) that is not correct, that incorrect information is called a fault. When the fault causes the software to behave in an incorrect manner or produce incorrect results, that behavior is called a failure. An example of an error is when a developer mistakenly believes that the diameter of a circle is three times its radius. This error could lead to a fault in the requirements document if this developer writes a requirement that says that the system, when given a radius as input and a command to compute the diameter, should return three times the radius. Or, the error could lead to a fault in the design if the design for the module for converting radii into diameters includes the faulty formula. Or, if the formula relating radius and diameter is not specified in either the requirements or the design, a fault could still be introduced in the code if the developer encodes his/her erroneous understanding of the formula. If the fault is introduced in the requirements or the design and propagates to the code, then it may become a failure if that part of the code is exercised and consequently produces a wrong output. However, if the test data contained a fault that caused the code for computing the diameter not to be executed during test, then this would allow a failure to occur during operational use, when that code is exercised. 4. A count of faults is 2 misleading measure of product quality because there usually is not a one-to-one correspondence between faults and failures. If many faults are located in code that is never or rarely executed, then they are unlikely to result in many failures, which is usually a more relevant measure of quality. On the other hand, if just one fault is located in code that is exercised heavily in regular use, it could result in numerous failures, and thus low-quality software. Furthermore, neither a count of faults nor a count of failures gives an indication of the severity of the problems. 5. In one small division of NASA, a group of software developers who developed software to support satellite missions decided to build an object-oriented library of software components. It was estimated that such a library would drastically reduce development time in this division, and would even allow the physicists and flight dynamics analysts in the division to put together their own applications rather than relying on software developers to write the programs they needed for mission support. The library was built using an architecture based on many years of experience in this domain, using sound software engineering principles, and was tested extensively. The components in the library were of very high technical quality. However, the library was of limited value to its intended customers, the physicists and analysts, because there were no tools or documentation that facilitated its use. Users of the library had to have a deep understanding not only of the application domain, but also of object orientation and software development, as well as the structure of the library itself. Thus, the library was not the success it was hoped to be. 1

  2. Page 2
    Read page 2 as text

    Downloaded from StudyXY.com ® + StudyXY Sd Ye. o> \ | iF ’ pr E \ 3 S Stu dy Anything This ContentHas been Posted On StudyXY.com as supplementary learning material. StudyXY does not endrose any university, college or publisher. Allmaterials posted are under the liability of the contributors. wv 8) www.studyxy.com

  3. Page 3
    Read page 3 as text

    The Therac 25 case is a good example of the dangers of narrowing the definition of quality. The developers of the software no doubt had tested the software extensively and considered it to be high quality. However, what was relevant was the quality (in particular, the safety) of the system as a whole: software, hardware, and operator. Because the Therac 25 developers adopted such a narrow view of quality, lives were lost. 6. The advantages of using COTS software packages include lower development costs, and no responsibility for maintenance. The disadvantages include unknown reliability, risk of vendor dropping support or refusing to make needed changes or demanding unreasonable prices for future support, and the vendor’s claims being misleading. Developers, customers, and users must anticipate the possibility of having to abandon the COTS product and having to replace it with locally written code or another COTS product. In other words, there must always be a contingency plan. 7. Ideally, the originators of the software that failed should be responsible for the consequences. However, it is often not possible to determine precisely what part of a system caused a failure, and it is often a combination of factors, or misunderstandings between the developers of the system itself, subcontractors, and/or COTS developers. One way to resolve the issue is to specify carefully such legal responsibilities ahead of time in the initial contracts. For example, the lead company might be willing to take on all liability for failure in exchange for additional cost savings from the COTS vendor or subcontractor. In this case, of course, the company will want extensive evidence of the quality of the software it is buying. Standard measures of quality (if they existed) would be helpful. At the very least, particular tests can be specified ahead of time that the software must pass before being accepted. 8. For example, the rule that advertisements for alcohol may be shown only after 9pm should be kept within the system boundary since the content and time of the advertisement are necessary pieces of information for the system to keep track of anyway and it would not be too difficult for it to check for conformance to this rule. On the other hand, it may become too complicated for the system to keep track of the content of advertisements in general. In that case, it could not include this constraint within its boundary. A similar argument could be made for the rule that if an advertisement for a class of product (such as an automobile) is scheduled for a particular commercial break, then no other advertisement for something in that class may be shown during that break. If advertisement content information can easily be tracked at the proper level of detail to enforce this rule, then it makes sense to keep it within the system boundary. Another rule states that if an actor is in a show, then an advertisement with that actor may not be broadcast within 45 minutes of the show. In order to include this constraint within the boundaries of the system, the system would have to keep track of all actors appearing in all programs and all advertisements. This information is considerable and not otherwise useful for the system to handle, so it would make sense for this constraint to be left outside the system boundary. 9. One reasonable way to assess the impact of a failure is how severely it affected people and how many people it affected. It is part of the job of the media to assess the impact in terms of the amount of damage (i.e. money or injury) and how much of society is affected (i.e. all taxpayers or the investors in a particular business). The Ariane-5 incident involved a large amount of money “owned” by many people (taxpayers). The failure of the Panix system, presumably, only affected its users and investors. Therefore, by this measure, the Ariane-5 incident had more impact and thus deserved wider coverage. However, of course, there are deeper issues. Perhaps a particular incident that had little impact itself may be indicative of problems in the same or another system that could cause much bigger problems later. It may be considered the job of the media to bring the public's attention to such potential problems. For example, the Panix failure could provide an opportunity to educate the public about the potential dangers of Internet “invasions.” 2

  4. Page 4
    Read page 4 as text

    Chapter 2: Modeling the process and life-cycle _——— 1. Determining the process boundary is similar to determining a system boundary. One must decide exactly which activities, inputs, and outputs the process includes, and which are part of some other process. For example, in specifying a software development process, one must decide if it begins with writing the contract for the software, or if it assumes the contracting process has already taken place and the contract is finished. Also, both systems and process models can be decomposed into subsystems and subprocesses. Both can be decomposed in at least two different ways. Subsystems and subprocesses could be parts of the larger system or process which, when put together, constitute the whole. Or, the arrangement could be in layers, as in Figure 1.10. Both systems and processes can be modeled at different levels of detail and from different perspectives in order to understand them, and to discover their strengths and weaknesses. 2. Waterfall: Benefits: simple, familiar to most developers, easy to understand easy to associate measures, milestones, and deliverables with the different stages Drawbacks: does not reflect how software is really developed not applicable for many types of development does not reflect the back-and-forth, iterative nature of problem solving V model: Benefits: better spells out the role of different types of testing involves the user in testing Drawbacks: extensive testing may not always be cost-effective some of the same drawbacks as waterfall Prototyping: Benefits: promotes understanding of problem before trying to implement solution reduces risk and uncertainty involves user in evaluating interface Drawbacks: in systems where the problem is well understood or where the user interface is simple and straightforward, the extra time spent in prototyping is not warranted prototyping can use up a Jot of resources, especially if the prototype fails completely and must be scrapped Operational specification: Benefits: allows user and developer to resolve requirements uncertainty early on Drawbacks: upfront investment may not be warranted if problem is well understood Transformational: Benefits: eliminates large steps of the process, thus reducing cost and opportunity for error provides automatic documentation Drawbacks: needs a very precise formal specification Incremental or iterative development: Benefits: reduces time to when customer receives some product customer training can begin early creates markets for new functionality 3 I~ StudyXY

  5. Page 5
    Read page 5 as text

    frequent releases allow problems to be fixed quickly expertise can be applied to different releases Drawbacks: customer may not be satisfied with an incomplete product or with frequent changes to system product may never be “complete” problem may not be easily decomposable changes may have to be made to completed parts in order to work with new parts Spiral: Benefits: monitors and controls risks throughout process easily incorporates prototyping Drawbacks: alot of overhead 3. Waterfall: re-analyze requirements, redesign, recode, retest V model: same as Waterfall Prototyping: prototype change in design and code, iterating with customer Operational specification: re-transform specification Transformational: re-do relevant transformations Incremental or iterative development: implement change in another increment or iteration Spiral: implement another mini-spiral 4. EEE EE SORT EER aaa no PN Ao oN Pe oN No Ne 4 <7 7 yes yes Es Sip Ravere | 4 | 8 — Study)

  6. Page 6
    Read page 6 as text

    5. This is the artifact that represents a class of software modules. Comply 7 (module user-defined) ET a identified ((state_of{module-spec(module)) = | Module is identified in exists) the specification but (state_of{module.implementation) = | has not been nonexistent) implemented yet. (state_of{module.test) = untested)) initial_implementation ((state_of{module.implementation) Module has been = initial) initially implemented, (state_of(module.test) = untested) | but has had no testing. resting (((state_of{module.implementation) | Module is being tested = initial) or and bugs being fixed. (state_of{module.implementation) = revising) (state_ofmodule.test) = partial) complete ((state_offmodule.implementation) Module is complete. = final) (state_of{module.test) = complete)) Shwe] Reworier ——[ ——————] The part of the spec pertaining to the module. 6. |“ REQUIREME? S se RTA Basan [sted | [stan] she ohm BETA EE | oPERMIK Seg | iRrae: 5 | — Study

  7. Page 7
    Read page 7 as text

    7. They would all be nice, but the only ones that are essential are that the model facilitates human understanding and communication and that it supports process management. Projects in which the problem and solution are not well-understood need to have as flexible a process as possible, which in most cases means that the process should not be defined at too detailed a level of granularity. In addition, as few resources as possible should be taken by purely process issues because they need to be devoted to understanding the problem and solution. Therefore, process improvement, guidance, and enactment should not be top priorities for the project. On the other hand, the model should facilitate following the process with as little effort as possible, so it should facilitate understanding and communication. Also, such projects can easily get out of control, so process management should be important. 8. Like manufacturing, there is a concern in software development with assuring the quality of the product, and many resources are spent in assessing and improving that quality. As well, both manufacturing and software development require careful planning and monitoring of the process. However, software development is creative in the sense that nearly every problem is new and requires a solution that is at least partly something that has never been done before. Therefore imagination must be used to envision how and if the solution will work. 9. The advantage of adopting a single process model for all software development in an organization is that it standardizes training, terminology, the collection of process metrics, planning, and estimation. This works well if all the organization’s development projects are very similar in nature. If not, however, adopting a single standard process may unnecessarily constrain some projects from using the process that is best suited to the problem and solution. 10. Conformance to a particular process is often checked with the use of milestones. That is, the process is defined in such a way that there are tangible products at various points in the process whose existence indicates that particular process steps have been carried out. For example, when using the waterfall process, these intermediate products, or milestones, could be a requirements document, a design document, the code itself, test documents, etc. The timing of these products would indicate whether or not the process was being followed as planned. Another way to monitor use of a process is by measuring effort. Developers working on the project could be required to report the effort they spent on different process activities. By tracking when effort is spent on which activities, progress through the steps of the process could be monitored. 11. Both the incremental and iterative models provide a great deal of flexibility to accommodate requirements changes. They differ, however, in what types of requirements changes they handle best. The incremental model is good at handling requirements changes which add or delete whole areas of functionality because each increment adds to the system in terms of functions. So, if a new function is added to the requirements, its implementation can be planned as part of a future increment. If a function is deleted, it may not even have been implemented yet, and can be deleted from the plan for a future increment. On the other hand, the iterative model best handles requirements changes which modify functionality, rather than adding or deleting it. In iterative development, every function is implemented at the beginning, but refined through successive iterations. Since most functions are modified in each iteration anyway, it is usually not difficult to incorporate modifications due to requirements changes. 12. The main issue is who is responsible for the failure of the software, and for any reparations necessitated by that failure. Ethically, you should have done everything in your power to ensure that the software was defect-free. That would include performing code reviews because you, as a software developer, know that code reviews are a valuable tool in locating software faults. Legally speaking, however, you were not required to perform code reviews. Moreover, you may have been prevented from performing those code reviews, either by a lack of resources provided by Amalgamated, or even by the terms of the contract, which may prohibit all process activities not specifically prescribed. In that case, Amalgamated would at least share responsibility for the software failure. 6 StudyXY

  8. Page 8
    Read page 8 as text

    Chapter 3: Planning and managing the project 1. Activities: Duration (in minutes): A. Choose recipe 30 B. Assemble cake ingredients 10 C. Prepare cake pan 2 D. Preheatoven 15 E. Mix dry ingredients 5 F. Mix wet ingredients 10 G. Fold wet ingredients into dry ingredients 3 H. Pour batter into pan 1 I. Bake cake 35 J. Assemble icing ingredients 5 K. Mix icing 10 L. Cool cake 30 M. Apply icing 10 Activity Graph: @) sTART 30 15 10 ® s ; 1 10 s © 30 10 € > FINISH Critical Path: A-B-F-G-H-I-L-M 129 minutes 7 + StudyXxy

  9. Page 9
    Read page 9 as text

    2. EO I ER LE ER LR mw from .. to: EJ EE ER IN EN EN EI A CR LI EA LN A LI EI LN LN EA LA LN LA ER LA LI A LO LR LI EEA LA LA LI EES LA LA CR LE EN LN LN LE LI LN EN I ER Critical path: A.B.D_L.J.L 20 days 3. Critical path: A.B.C.E.D.I.K.L 24 days 4. Test planning can take place in parallel with requirements, design, and coding activities. Low-level design and coding on different parts of the system can take place in parallel. Activity graphs might 8

  10. Page 10
    Read page 10 as text

    hide interdependencies because you cannot represent the fact that the results of a particular activity may require re-doing part of a previous activity. Also, a complex interdependency between two activities may not require that one be completed before the other. There are other types of interdependencies, e.g. information dependencies. 5. Adding personnel requires extra time for training as well as a superlinear increase in communication channels and thus communication costs. These added costs may outweigh the time savings from having extra people working on the project. 6. The Hardand estimate would be 5.25 * (20000)*" = 43,062 person-months. If the size estimate is 10% too low, then it will take 4,332 more person-months to complete. If we express as a fraction, rather than a percentage, then the relationship between the original estimated size, S,, and the actual size, S,, is Se=S./ (1k) and the relationship between the original estimate, E,, and the actual needed time, E, is E = 5255 = 5.25(S./(1-k)” = (Ik) *52557 = (1-R) *E, If k is 10% (or 0.1), then the above formula yields 47,395 person-months, which is 4,332 more than the original estimate. 7. A utility program usually takes longer to develop than an applications program because the developer has to take into account all of the different environments in which it might be used. For instance, a sort routine must be callable from many different other programs, and it has to return its output in some “generic” way that can be used by an assortment of other components. On the other hand, an applications program is usually very specific. It has a much narrower scope, and the set of possible calling programs is much smaller. Its output is usually tailored for the very small number of other programs that need it. A systems program, being even more general than a utility program, has a larger set of possible callers, and it must be even more generic. So it can take a longer time to specify the set of calling and receiving programs, and it is likely to have a lot of cases to handle, especially in its error-handling. 8. Factors to consider include: * how long it would take to build in-house; * how soon the software is needed * how many programmers would be needed; * whether or not the technical and managerial expertise is available in-house; * the quality of the purchased software; * maintenance costs, both in-house and through the vendor It is generally better to build when the expertise is already available in-house, when the organization is willing and able to take on maintenance of the system, or when there is uncertainty about whether or not the purchased software would meet quality requirements. It is generally better to buy when the software is needed sooner than it can be built in-house, or when it can be bought much more cheaply than it can be built. 9. Yes and no. Development time, strictly defined, may be shortened by adding more people, but actual project time would probably increase due to increased training, communication, and management effort. It also depends a great deal on when in the project lifecycle people are added. A project that starts out with more people will probably finish earlier than if it had started out with fewer people. However, adding those people nearer to the end of the project is less likely to be beneficial. 10. The Bailey & Basili model reflects the first factor through the cost factor “customer initiated program design changes.” COCOMO Stage 3 addresses the latter through the factor “personnel continuity.” 9 | — StudyXY

  11. Page 11
    Read page 11 as text

    11. Teams of three students each implemented an automatic car wash control system in 90 days as part of a software engineering course. Below are some of the risks, the corresponding exposures, and possible mitigating actions. unable to agree on design (:30)(10) = 3 days pick one chief designer who makes all decisions one member not working (.10)(30) = 3 days choose team members; appeal to professor 12. Unit size per unit time is an unsatisfactory measure of productivity for several reasons. Unfortunately, it is pretty much the only measure available. Some of the reasons it is inadequate: * programmer output varies widely ® size per time varies according to application language, application domain, difficulty, and newness of problem * amount of reuse also affects productivity * management style and structure * programmer style can vary according to the targets given to them * values for size are not available until long after estimates are needed, and size estimates can be very inaccurate Consequently, it would be very helpful to have a measure for productivity that overcame all of these shortcomings. Furthermore, we need to understand some of the surrounding issues, such as the effect of productivity targets, management style, and programmer expertise on productivity, no matter how it is measured. 10 | — StudyXY

  12. Page 12
    Read page 12 as text

    Chapter 4: Capturing the Requirements 1. Developers, customers, and users all bear some responsibility for the situation, as they all had input into the requirements of the system. However, the developers (or the development organization) should probably bear most of the responsibility because they, as software professionals, should have the expertise to ensure that the requirements are complete. 2. No system can be built to be safe and reliable in all environments and under all conditions. Therefore, we need to explicate any assumptions we make about the environment, about input values, and about the ordering of inputs. Such non-functional requirements must explicitly specify all of the situations and conditions under which the system must not fail. The context and the environment in which the system will be running become pre-conditions for stating and satisfying its safety and reliability requirements. For example, “the system must not fail catastrophically when the user supplies a non-valid numerical input.” Ideally, the requirement should also specify what the system should do in such a situation (e.g. give a meaningful error message to the user and continue processing). The problem with specifying the requirement to “never fail” is that it does not explicitly state all of the situations in which the system must not fail, therefore it is not testable or demonstrable. Confidence that a system meets this requirement can be built up, however, by testing under as many conditions and in as many different situations as possible, and by soliciting input from users and other experts about the different situations that could be tested. 3. a) The client daemon must be invisible to the user Design constraint, referring to distributed solution Functional requirement related to user interface b) The system should provide automatic verification of corrupted links or outdated data Functional requirement ¢) An internal naming convention should ensure that records are unique Functional requirement related to data constraints d) Communication between the database and servers should be encrypted Quality requirement referring to the security of the system e) Relationships may exist between title groups [a type of record in the database] Functional requirement referring to data relations f) Files should be organizable into groups of file dependencies Functional requirement related to data constraints g) The system must interface with an Oracle database Design constraint referring to the interface with other systems h) The system must handle 50,000 users concurrently Quality requirement referring to the performance of the system Items d and f may be premature design decisions. They could be rewritten as: d) Internal data stores and communications should be secure against illegal accesses f) Dependencies among information should not be cyclic In addition, items a and c refer to design constructs (e.g. clients, internal naming conventions). These requirements could be better expressed by eliminating reference to these constructs: a) User should believe that he is interacting with a centralized system ¢) All records must be unique

  13. Page 13
    Read page 13 as text

    4. Decision table: rr [RI[RITRATRS [RG [RE [RY [RIO] [blackswrn [TT] -]-]F]F[-]-] [ black has a legal move available | T | F | - | - | - [ - | - | -| [red has alegalmoveavailable [| - | - | - | - [TF [-]-] black marker reaches red side of the T board red marker reaches red side of the - - - - - - T - board [black'swmover | [XT PTT TT [redswmover [| | | | [xX[ [| | red makes a move X [blackmakesamove [x [ | | [| [| | [black markerisking'ed [| Ix] | | [| | [redmarkerisking'ed | [| | | [|X] | [gameoversblackwins [| | Ix | [| | game over; red wins X 5. The specification is contradictory if there are two columns which specify the same condition (same set of truth values) but different actions. The specification is ambiguous or incomplete if there are some conditions for which there is no column (i.e. no specified action). 6. b -dac<0 b -dac=0 5 -dac>0 -b —b++b* —dac quadratic_real_roots (a,b,c) = XX 2a wm

  14. Page 14
    Read page 14 as text

    7. A state-machine specification to illustrate the requirements of an automatic banking machine (ABM). acceptance card PIN from bank withdraw(amount) CONS SON la NN la ’ BY Ie Ia IY I's IY — idle wait for PIN authenticate get user request | check balance \ JN J \ AEN Jo J — SE \ ya money Acard returned balance >= amount] ~ 4 RY ~~ process request | _ "7 do /number_of bills := amount20 € L exit money:= number_of_bills X20 | SEA Note: This state machine shows only the operation of withdrawing cash. Other operations can be modeled in a similar way. 8. A state-machine for the ABM including a trap state. session pi any input / JES _ outofbills cancel / session terminated trap < insufficient EN card returned / “card returned \ ) funds \ noPN no user h \ 7 imeouy ~~ P29PNI request AN jd y, (imeout) \ / acceptance / lcd PIN from bank withdraw(amoun) ~~ v £ - L - Bl 4 , v4 No BY ~ —_— idle wait for PIN authenticate get user request check balance \ “money / / “\_ | “card returned balance >= amount] / ~ process request yd do /number_of bills := amount/20 € . exit money:= number_of_bills X 20 | — StudyXY

  15. Page 15
    Read page 15 as text

    9. Safety properties: e The amount of money returned by the ABM is never more than the amount requested by the client in the withdrawal. [1 (money = (money < amount) e The amount of money returned by the ABM is never more than the client’s balance. [J (money = (money < balance)) Liveness properties: e When an authenticated client specifies the amount of money to withdraw, and the client has sufficient funds in his account, and the ABM has sufficient funds to dispense, the ABM dispenses the requested amount of money [J (process req A amount < balance A amount £ ABM funds) = O (money =amount)) e When the client terminates the session pressing the cancel button, the ABM returns his card [J ((session A cancel) = O card returned) 10. Proof 1 : The amount of money returned by the ABM is never more than the amount requested by the client in the withdrawal. PROOF RATIONAL a. money given in formula b. ABM dispenses $20 bills assumption c. number_of bills = amount/20 action in state process request, a d. ABM has sufficient cash assumption e. money = number_of_bills x 20 action in state process request, ¢ f. money = (amount/20) x 20 substitution b in d g. money <= amount number _of bills is integer part of amount/20 Assumptions about the environment ABM dispenses $20 bills ABM has sufficient cash — StudyXY

  16. Page 16
    Read page 16 as text

    Proof 2: The amount of money returned by the ABM is never more than the client’s balance: PROOF RATIONAL a. money given in formula b. ABM dispenses $20 bills assumption c. number_of bills = amount/20 action in state process request, a d. money <= number_of_bills x 20 action in state process request e. money <= (amount/20) x 20 substitution of b in ¢ f. amount <= balance guard on entering state process request g. money <= balance transitivity of <= Assumptions about the environment ABM dispenses $20 bills Proof 3: PROOF RATIONAL a. in state process request given in formula b. number_of bills = amount/20 action in state process request c. amount = (amount/20)x20 assumption d. ABM has sufficient cash given in formula e. money = number_of_bills x 20 action in state process request, ¢ f. money = amount substitution of a, b into d g. O (money=amount) no guard on transition leaving state process request Assumptions about the environment Amount request is divisible by 20 Proof 4: PROOF RATIONAL a. session given in formula b. cancel = O (card returned) guard and action on transition leaving c. amount = (amount/20)x20 state session 11. Some factors to consider in this decision are * Who will be building the prototype? If they have a good understanding of the requirements, then they could write the requirements after the prototype has been evaluated. Otherwise, they will need some guidance or documentation, and a draft of the requirements should be written by someone else so that the prototype builders can use them. | — StudyXY

38 more pages in the full document

Unlock it once and it stays in your library, ready to chat with or turn into flashcards.

Unlock the full document

More Information Technology study materials

See all

Study this document with CramX

Once it is in your library, every tool can work from it.