Requirements analysis and documentation is important to decide how to distribute the work across teams and to ensure that each team has some understanding of what other teams are doing. Design documentation especially interface specifications are important so that teams can develop independently without having access to software that is under development.
Risk management may be required to ensure that all of the teams understand the risks faced and can organize their work to minimize these risks. Risk management may also be useful to cope with different delivery schedules used by different teams. That is, they adopt the outlook of the development team and lose sight of the needs of their user colleagues. Suggest three ways how you might avoid this problem and discuss the advantages and disadvantages of each approach.
Involve multiple users in the development team. Advantages are you get multiple perspectives on the problem, better coverage of user tasks and hence requirements and less likelihood of having an atypical user.
Disadvantages are cost, difficulties of getting user engagement and possible user conflicts. Change the user who is involved with the team. Advantages are, again, multiple perspectives. Disadvantages are each user takes time to be productive and possible conflicting requirements from different users. Validate user suggestions with other user representatives. Advantages are independent check on suggestions; disadvantage is that this slows down the development process as it takes time to do the checks.
Software Engineering 10 — Solutions Manual 4 4. Users select their destination and input a credit card and a personal identification number. The rail ticket is issued and their credit card account charged. When the user presses the start button, a menu display of potential destinations is activated, along with a message to the user to select a destination and the type of ticket required.
Once a destination has been selected, the ticket price is displayed and customers are asked to input their credit card. Its validity is checked and the user is then asked to input their personal identifier PIN. When the credit transaction has been validated, the ticket is issued. Ambiguities and omissions include: 1. Can a customer buy several tickets for the same destination together or must they be bought one at a time?
Can customers cancel a request if a mistake has been made? How should the system respond if an invalid card is input? What happens if customers try to put their card in before selecting a destination as they would in ATM machines?
Must the user press the start button again if they wish to buy another ticket to a different destination?
Should the system only sell tickets between the station where the machine is situated and direct connections or should it include all possible destinations? Software Engineering 10 — Solutions Manual 4.
Possible non-functional requirements for the ticket issuing system include: 1. Between and in any one day, the total system down time should not exceed 5 minutes. Between and in any one day, the recovery time after a system failure should not exceed 2 minutes. Between and in any one day, the total system down time should not exceed 20 minutes. All these are availability requirements — note that these vary according to the time of day.
Failures when most people are traveling are less acceptable than failures when there are few customers. After the customer presses a button on the machine, the display should be updated within 0. The ticket issuing time after credit card validation has been received should not exceed 10 seconds. When validating credit cards, the display should provide a status message for customers indicating that activity is taking place.
This tells the customer that the potentially time consuming activity of validation is still in progress and that the system has not simply failed.
The maximum acceptable failure rate for ticket issue requests is 1: I have not specified the acceptable number of incorrect tickets as this depends on whether or not the system includes trace facilities that allow customer requests to be logged. If so, a relatively high failure rate is acceptable as customers can complain and get refunds.
If not, only a very low failure rate is acceptable. Obviously, these requirements are arbitrary and there are many other possible answers. You simply have to examine their credibility. Keeping track of the relationships between functional and non-functional requirements is difficult because non-functional requirements are sometimes system level requirements rather than requirements which are specific to a single function or group of functions.
One approach that can be used is to explicitly identify system-level nonfunctional requirements that are associated with a functional requirement and list them separately. All system requirements that are relevant for each functional requirement should be listed. They can be related by including them in a table as shown below. Functional requirement The system shall provide an operation which allows operators to open the release valve to vent steam into the atmosphere.
Related non-functional system requirements Safety requirement: No release of steam shall be permitted if maintenance work is being carried out on any steam generation plant. Non-functional requirements Timing requirement: The valve must open completely within 2 seconds of the operator initiating the action. Notice that in this example, the system non-functional requirement would normally take precedence over the timing requirement, which applied to the specific operation.
Obviously, any sensible answer that provides a way of linking functional and nonfunctional requirements is acceptable here. There are a variety of different types of ATM so, obviously, there is not a definitive set of use cases that could be produced.
However, I would expect to see use cases covering the principal functions such as withdraw cash, display balance, print statement, change PIN and deposit cash. The use case description should describe the actors involved, the inputs and outputs, normal operation and exceptions. The Withdraw cash option is selected. The customer is promoted with a request for the amount of cash required and inputs the amount.
Before the cash is dispensed, the card is returned to the customer who is prompted by the machine to take their card. Exception: Invalid card. Card is retained by machine; Customer advised to seek advice.
Incorrect PIN. Customer is request to rekey PIN. If incorrect after 3 attempts, card is retained by machine and customer advised to seek advice. Insufficient balance Transaction terminated. Card returned to customer. The current balance of their account is displayed on the screen. The card is returned to the customer. The last five transactions on their account is printed.
The PINS input should be the same. As in Withdraw cash. PINS do not match. The customer is promoted with a request for the amount of cash to be deposited and inputs the amount. He or she is then issued with a deposit envelope in which they should put the cash then return it to the machine. No cash deposited within 1 minute of envelope being issued. Transaction terminated. Suggest a model of a process for making these modifications that will ensure that the requirements document and the system implementation do not become inconsistent.
The following diagram shows a change process that may be used to maintain consistency between the requirements document and the system. The process should assign a priority to changes so that emergency changes are made but these changes should then be given priority when it comes to making modifications to the system requirements.
The changed code should be an input to the final change process but it may be the case that a better way of making the change can be found when more time is available for analysis.
Explain why it is not always necessary for such a system model to be complete and correct. Would the same be true if you were developing a model of a new system? You might create and use a model of a system that already exists for the following reasons: 1. To understand and document the architecture and operation of the existing system.
To act as the focus of discussion about possible changes to that system. To inform the re-implementation of the system. You do not need a complete model unless the intention is to completely document the operation of the existing system.
The aim of the model in such cases is usually to help you work on parts of the system so only these need to be modelled. Furthermore, if the model is used as a discussion focus, you are unlikely to ne interested in details and so can ignore parts of the system in the model. This is true, in general, for models of new systems unless a model-based approach to development is taking place in which case a complete model is required.
The other circumstances where you may need a complete model is when there is a contractual requirement for such a model to be produced as part of the system documentation. Courses may have limited enrolment, so the registration process must include checks that places are available.
Assume that the student accesses an electronic course catalog to find out about available courses. A relatively simple diagram is all that is needed here. It is best not to be too fussy about things like UML arrow styles as hardly anyone can remember the differences between them. Model the object classes that might be used in the system implementation to represent a mailbox and an e-mail message. Mail message sender: receiver list: cc list: bcc list: date: subject: return path: routing info: spam info: mailer: message info: message body: attachments: signature: read reply reply all print forward send Mailbox name: pathname: creation date: change date: messages: unread messages: flagged messages: deleted messages: move message copy message delete message fetch mail create rename delete Software Engineering 10 — Solutions Manual 5.
Notice that I have not developed the activities representing other services or failed authentication. Other services [other service] Get customer info Present service menu [withdrawal] Get amount Dispense cash [OK] Check balance Authenticate «system» Accounting system [insufficient] Authentication failure 5.
GDPR compliance: I do not set cookies or store personal information about visitors to this site. The latest tenth edition of my Software Engineering textbook was published in I have extensively revised and…. All of the case studies that are shown here are used in the book.
I have deliberately not used a single case study…. The links below are links to the slideshare presentations for each chapter of the book. You can view the presentation or…. Many people find videos helpful in developing their understanding so I have made a number of videos on a range of…. I have designed by textbook to be a hybrid print-web book and the supplements here provide additional information over…. Software Engineering, Tenth Edition A comprehensive textbook on software engineering The tenth edition of my Software Engineering textbook was published in April
0コメント