1) An ATM SRS has a requirement to allow for cash withdrawals in $20, $10, and/or $5 denominations.
a) Name the stakeholders for this system. (10 pts)
Below are all the possible stakeholders from the beginning of the development phase to the end phase.
ATM Engineer - Maintenance of the equipment by the bank’s engineers. This action may be initiated by the engineer on a routine basis. It may also be initiated by the equipment that can call the engineer when it detects an internal fault.
Property / Shop Owners: Unloading of deposits and loading of cash by officials of the ATM owner. These actions occur either on a scheduled basis or when the central computer determines that the cash supply is low or the deposit receptacle is liable to be getting full. This stakeholder group concerns people who might live next to or close to an ATM machine. For example, many ATM machines can be found on the high street and perhaps only a few floors above will be someone's property. This group also includes shop owners as many ATM machines can be found located next to a shop.
Audit: An audit trail for all activities will be maintained and sent periodically to the bank’s central computer. It will be possible for the maintenance engineer to save a copy of the audit trail to a diskette for transporting to the central computer.
System Test Engineer – Bothe dialup and leased line support will be provided. The ATM will continue to provide services to customers when communications with the central computer is not available. Also system test engineer keep update the system.
ATM Manufacturers: Manufacturers are at the top of possible stakeholders as they provide the product to the other stakeholder groups.
Companies/Banks: This stakeholder groups covers many different areas as it is not necessarily just banks that will invest in ATM machines. Places such as petrol stations, clubs, pubs, universities now have ATMs also.
ATM Users: They are one of the most important stakeholder groups as they are the people who are using the products, without them there would be no point for the production companies and banks to invest in ATM machines.
The Employee Population: There are a few possible stakeholder groups that can come under this heading but one of the most important is the people whose work environment is situated around or next to an ATM machine. This could be bank workers, petrol station employees, barmen/women, supermarket employees etc.

b) Analyze this requirement. Do you recommend keeping it or changing it? Defend your answer. (10 pts)
Service- To allow for cash withdrawals in $20, $10 and/or $5 value
Function – The ATM is used by bank or customer for many reasons. Many years ago, there was limited functionality, but today, customer can perform various functions such as cash withdrawal, deposit, balance inquires, money transfers, and stamp purchases.
Cash withdrawals
The most common function of the ATM used by customer is to withdraw money from a their savings or checking account.
Deposits
Similarly, most ATMs allow deposits to be made to both checking and savings accounts. These deposit functions usually require cash or checks in envelopes, and can sometimes be accomplished by credit card. The modern ATM allows checks only deposit, were checks are scanned with ATM scanner and doesn’t require envelop or to enter any amount.
Balance Inquiries
Another common function of the ATM is the ability to check account balance, for savings or checking, and to print out that balance for future reference.
Money Transfers
Money transfer is a popular function for those who carefully manage the funds in more than one account, and can be used to move funds from one account (for example, a checking account) to another (like a savings account).
Stamp Purchases
An increasingly popular function of modern ATMs is the ability to buy stamps. Although this functionality is not available at all ATMs, its popularity has been sufficient for its availability to expand.
Function requirements
Functional requirements are as below:
1) Requirement of the ATM
i) Authorization process ii) Withdrawal process

2) Requirement of the bank computer
i) Authorization process like Bank ATM card and PINCODE. ii) Transaction
Non-functional requirement
Non-functional requirement are as below:
1) Connection of the network with the ATM system is 24 hours per day.
2) Each bank may be processing transaction from several ATMs at the same time.
3) The ATM must be able to use several data formats according to the data formats that are provided by the database of different banks.
The requirements are keep changing according to Customer’s feedback taken via survey and import the new flexibility into the existing system. Constraints under which the system must operate, the users and tester knows well during their frequently uses. The system, which was going to be implemented, obviously will change the working environment but that must not be drastic and the users must feel comfortable handling and user friendly system.
Below Context Level Data Flow Diagram indicates each process as one entity.

2) Related to Requirements:
a) Why don’t we put the design in the Requirements? What should be in the Software Requirements Specification (SRS)? (10 pts)
A Software Requirements Specification (SRS) is typically developed during the first steps of software requirement development. In this phase, only information is gathered about customer’s requirement are needed and what not. This gathering process includes processes like meeting, survey, onsite visits, interviews, questionnaires, and analysis of client business environment. After gathering all these information, actual Software Requirements Specification is written. At this stage, a design suggestion is not offered.
A Software Requirements Specification (SRS) only contains functional and nonfunctional requirements and doesn't contain design document, possible solution or any issues. SRS contains customer's system requirements that will understand development team. In a simple form, a Software Requirements Specification (SRS) is essentially an organization's understanding of a client or their system requirements and dependencies at a particular point in time.
The following tasks should be considered when writing well-design and well-written SRS document:
-SRS should be written in normal language such as it includes charts, tables, DFDs, decision tables, and much more.
-Break down problems into various components and organize properly.
-SRS must contain sufficient detail in the functional system requirements
-Product validation check strategies should be applied to fulfill requirement for verification.

The basic issues that the SRS document should address are the following:
a) Functionality: What is the software supposed to do?
b) External interfaces: How does the software interact with people, the system’s hardware, other hardware, and other software?
c) Performance: What is the speed, availability, response time, recovery time of various software functions, etc.?
d) Attributes: What is the portability, correctness, maintainability, security, etc. considerations?
e) Design constraints imposed on an implementation: Are there any required standards in effect, implementation language, policies for database integrity, resource limits, operating environment(s) etc.?

b) Are there times we can’t avoid putting design into the SRS? Explain. (5 pts)
These days, the software and system requirement is so complex that putting a design into SRS is very risky, and how someone will create a design without knowing what is required to build. In order to reduce the development effort, the preparation of the SRS forces the various concerned groups in the customer’s organization to consider severely all of the requirements before design begins and reduces later redesign, recoding, and retesting work. The SRS is often referred to as the master document because all subsequent project management documents, such as design specifications, statements of work, software architecture specifications, testing and validation plans, and documentation plans, are related to it. The SRS documents should have just functional and nonfunctional requirements, and not any kind of design suggestion or technology or business issues.
At last, I would not say that there are any times we can’t avoid putting design into the SRS.
c) Can you ever guarantee that there will be no changes to approved and baselined requirements? Defend your answer.(5 pts)
We cannot really guarantee of changes to approved business requirements and baseline documents. The requirements can be change if new management is involved, or new Stakeholders are added. Usually, the baseline document sets the standard for Business Requirements and is available to all Stakeholders. For any security reason, if Business standard Requirements is changed, than changes to approved requirement and baseline document is needed. The document forms the basis for all work performed on the project for which it was developed for and identifies an organization's expected capabilities without limiting its potential to pursue unexpected opportunities. The baseline document also helps determine the estimated level of improvement that may be achieved through the realization of the Business Requirements. The baseline becomes, in effect, an organization's operational Bible.
Changes are also varying based on user’s survey and also from Stakeholder feedback. Users are especially likely to spot deficiencies in Business Requirements or to propose improvements not previously considered. Any proposed changes must be made via a formal request and will be reviewed in relation to possible impact on requirements baseline. Making changes may involve further study and repetition of the Requirements Management Process. The baseline is not a static document but rather organic in nature. Changes to the Business Requirements Document will continue throughout the project and throughout useful life of the document.
3) Related to Prototyping:
a) What are the advantages of static prototyping? (5 pts)
Static prototyping, also called low-fidelity prototyping, relies on mockups, storyboarding and paper and pencil strategies. This is followed by dynamic or high fidelity prototyping with the construction of the actual interface using User Interface Builders. The various manufacturers as well as windowing systems come with user interface design guidelines as to how to make the system user-friendlier. These builders also generate programs for the user interface layer, which can directly be integrated with application, and data layers.
Static Prototypes can help avoid technology risks. Static Prototypes are developed with well-known and less risky technologies such as HTML, CSS, and JavaScript. As these technologies are proven and low risk, it is unlikely that the Static Prototype will be delayed or cost more than expected.
b) Define Throwaway Prototyping. When should we use it? (10 pts)
A prototype developed as part of a throw-away approach will not form part of the final solution. It is likely to inform the final solution, but the prototype itself will not become part of the final solution.
Throw-away prototypes are a useful way of exploring ideas, and gaining feedback from the client and/or end-user. They tend to be used to answer questions. They are then discarded.
The speed at which throw-away prototypes can be generated and modified is a major reason for their use and why this method is sometimes referred to as 'rapid prototyping'.
They also provide a useful and meaningful way for a developer to walk the client and/or end-user through the system requirements as interpreted by the developer. Feedback from the client and/or end-user should aid in allowing misinterpretations or unnecessary complexities to be picked up and addressed at an early stage.
The speed of development and the potential to catch misinterpretations or missing features at an early stage can help to make the throw-away prototype a cost effective approach.
c) How does Evolutionary Prototyping differ from Throwaway Prototyping? (5 pts)
Evolutionary Prototype:
The evolutionary approach aims to develop a mature system through a series of prototype iterations. This approach is particularly useful when the exact requirements of the solution cannot be set out in advance, or are considered to be vague. The client and/or end-users can become closely involved the development, playing a key role as each iteration moves further from prototype and closer to a useable solution that does what it is needed to do, and does it well. When a prototype is designed and is transformed into the workable piece of software, then it’s called a Evolutionary Proto Typing. Means, the prototype designed is used to explain the software system to be designed. And then the same proto is added with all the functionalities that are mentioned in the BRD (Business Requirement Document) or SRS (Software Requirement Specification)
Evolutionary prototyping model is a software development lifecycle model in which software prototype created for demonstration and requirements elaboration. Evolutionary prototyping model includes the four main phases:
-Definition the basic requirements
-Creating the working prototype
-Verification of the working prototype
-Changing or elaboration the requirements
Throw-away Prototype:
As the name indicates, it is just used as a reference in a software development process. Unlike, Evolutionary Prototyping, Throw-away prototype is going to be a model for the software, and its not going to be the product. Here, the Prototype is developed mostly with tools which can be used for designing. Whereas the software is developed in some other language / tool / IDE.
4) What are the Pros and Cons of Waterfall SDLC and Spiral SDLC? (20 pts) The waterfall model shows a process, where developers are to follow these phases in order:
-Requirements specification (Requirements Analysis)
-Design
-Implementation (or Coding)
-Integration
-Testing (or Validation)
-Deployment (or Installation)
-Maintenance
The waterfall model is simple, easy to learn, and easy to use. In this model, after each phase is finished, it proceeds to the next one. Reviews may occur before transitioning to the next phase which allows for the possibility of changes (which may involve a formal change control process). However, it discourages revisiting and revising any prior phase once it's complete. This "inflexibility" in a pure Waterfall model has been a source of criticism by other more "flexible" models.
Pros:
- Enforced discipline through documents. It is documentation driven, that is, documentation is produced at every stage.
- No phase is complete until the docs are done & checked by SQA group.
- Concrete evidence or progress.
- Testing is inherent in every phase.
- Testing is natural to every phase of the waterfall model
- It is an enforced disciplined approach.
Cons:
- No fair separation of phases in the life cycle.
- The following phase should not start until the previous phase has finished
- Document driven model as a result customer cannot understand these.
- Re-design is problematic.
- It only incorporates iteration indirectly, thus changes may cause considerable confusion as the project progresses.
- As the client usually only has a vague idea of exactly what is required from the software product, this model has difficulty accommodating the natural uncertainty that exists at the beginning of the project.
- The customer only sees a working version of the product after it has been coded. This may result in disaster if any undetected problems are precipitated to this stage.
-

The key characteristic of a Spiral model is risk management at regular stages in the development cycle. This approach focuses clearly on the objectives of the effort from several different viewpoints. These same viewpoints are employed in different contexts and the context changes each time around the spiral. It encourages the reuse of code and exploration of alternatives.
Pros:
- This model has high amount of risk analysis
- It is good for large and mission-critical projects.
- Software is produced early in the software life cycle.

Cons:
- It is very expensive model to use.
- Risk analysis requires highly specific expertise.
- Each project’s success is highly dependent on the risk analysis phase.
- It doesn’t work well for smaller projects.

5) Standards:
a) What is the difference between a Standard and a Process? (15 pts)
Standard: It is usually an official document that establishes consistent technical criteria, methods, processes and practices. A standard is an agreed, repeatable way of doing something.
IEEE Standard 1074 is one of a standard for the generation of the process governing software development and maintenance for a project. This standard requires selection of a user’s software project life cycle model based on the organization’s mission, vision, goals, and resources. It is not intended to define or imply a software project life cycle (SPLC) of its own. This standard describes the individual activities that are to be mapped within the selected model and provides examples of mapping onto typical simple Content Management System. However, this standard is not an instructional guide. In addition to providing for the generation of a project process, this standard may also be used to develop organizational processes to support software development and maintenance or to develop special, single-function processes within a project.
Standard are an excellent example of the freeing effect of certain constraints. Standards used in an organization regarding system development practice, quality management, etc. The international standard for describing the method of selecting, implementing and monitoring the life cycle for software is ISO 12207.
E.g. Assume that the library uses a hardware platform for all of its systems. A requirement from this might be the system shall run on a Sun server running the Solaris 2.0 operating system. So the Solaris 2.0 becomes Standard for the system.
Process: A Process defines what is to be done, and it will help avoid any mistakes. The description of processes is very important because they allow knowledge to be reused.
An example would be the process of software testing in an organization. In so doing, there are inputs (Requirements), activities (Test Planning and Execution) and outputs (Test Analysis Report). The objective of the process model is to show that an organization is meeting the generally prescribed testing activities in addition to performing adequate planning, review and approval along the way.
The Capability Maturity Model Integration (CMMI) is one of the leading models and based on best practice. Independent assessments grade organizations on how well they follow their defined processes, not on the quality of those processes or the software produced. CMMI has replaced CMM.
ISO 9000 describes standards for a formally organized process to manufacture a product and the methods of managing and monitoring progress. Although the standard was originally created for the manufacturing sector, ISO 9000 standards have been applied to software development as well. Like CMMI, certification with ISO 9000 does not guarantee the quality of the end result, only that formalized business processes have been followed.
ISO 15504, also known as Software Process Improvement Capability Determination (SPICE), is a "framework for the assessment of software processes". This standard is aimed at setting out a clear model for process comparison. SPICE is used much like CMMI. It models processes to manage, control, guide and monitor software development. This model is then used to measure what a development organization or project team actually does during software development. This information is analyzed to identify weaknesses and drive improvement. It also identifies strengths that can be continued or integrated into common practice for that organization or team.
Process needs the model, support and improvement.
E.g. A cookery book describes a set of processes to prepare and cook various different types of meal. The inputs to these processes are raw ingredients: the outputs are cooked meals.

b) Name a Standard used in the Software Development Life Cycle. (5 pts)
The following are the name of Standard used in the Software Development Life Cycle.
- ANSI/IEEE 1028: Standard for Software Reviews and Audits
- ANSI/IEEE 1058.1: Standard for Software Project Management Plans
- ANSI/IEEE 1074: Standard for Software Lifecycle Processes
- SEI/CMM: Software Project Planning Key Process Area
- Coding Standards
- Quality Assurance Standards
- Software safety assurance standards
- ISO 9000 standards
- ISO 15504 standards
- ISO 12207 Standards

References:

Gause, Donald, Weinberg, Gerald, Edwards, Paul, Edwards, Sarah, & Bakken, Suzanne. (2001). A Medical informatics odyssey. New York, NY: Dorset House Publishing.

IEEE Std 1074-1997 IEEE Standard for Developing Software Life Cycle Processes –Description Retrieved from http://standards.ieee.org/reading/ieee/std_public/description/se/1074-1997_desc.html

Japenga, R. (2008). How to Write a software requirements specification. Retrieved from http://www.microtoolsinc.com/Howsrs.php

Kotonya, Gerald, & Sommerville, Ian. (2002). Requirements engineering. Chichester: John Wiley & Sons.

Patwary, B.R. (2004). Analysis of an automated teller machine system . Retrieved from http://www.scribd.com/doc/3950894/Analysis-of-an-Automated-Tellr-Machine

Vir, D.L. (2007). Writing software requirements specifications. Retrieved from http://www.techwr-l.com/techwhirl/magazine/writing/softwarerequirementspecs.html

Standards IEEE (n.d.). Retrieved from http://standards.ieee.org

Software development process Retrieved from http://en.wikipedia.org/wiki/Software_development_process

The Software Development Life Cycle (SDLC) For Small To Medium Database Applications Retrieved from http://www.elucidata.com/refs/sdlc.pdf

Wikipedia, . (n.d.). Waterfall model. Retrieved from http://en.wikipedia.org/wiki/Waterfall_model