Assignment 4

Systems Analysis & Design Methods, by Jeffrey L. Whitten & Lonnie D. Bentley
Chapter 5

3. Two most popular approaches: discovery prototyping and Rapid Architected Analysis.
Discovery prototyping utilizes RAD-type resources like Microsoft Access to quickly create user
interfaces such as data input screens and notifications to help identify business needs and get
reviews from device users and proprietors. These models are actually like façades used in a
movie set; they look very realistic, but behind the façade there is really no structure, i.e.,
detailed database and programming. This is both the strength and weakness of prototyping – a
system analyst can very quickly create prototype models to identify business requirements, but
the same ease and speed of creating elegant-looking interfaces can lead to false expectations
about the actual system to be built by system users and owners.

Rapid Architected Analysis is close to exploring prototyping because in order to get input, it also
relies on designing structure models rapidly. But Rapid Architected Analysis builds these models
from existing systems, usually legacy ones, or from prototypes by using reverse-engineering
tools, such as CASE. Professional systems analysts never seek to use prototyping as a
stand-alone design tool that entirely eliminates model-driven design; in addition, through its
reverse engineering methodology, the Rapid Architected Analysis technique blends both
prototyping and model-driven methods.

4. The main question is: “Is this project worth looking at?”
In order to answer the question, the project team must answer following:
1.What is the scope of the project?
2.What was the trigger for this project?
3.For each problem, directive or opportunity, what is the assessment of their urgency, visibility,
tangible benefits and priority?
4.Will resolving the problems, carrying out the directives, and/or taking advantage of the
opportunities have a great enough ‘pay-off’ to justify the effort, cost and risk of conducting the
project?
The scope definition phase consists of five tasks:
1. Identifying the project triggers, such as the problems, directives, and oppor-tunities
2. Negotiating and reaching consensus on the baseline scope of the project.
3. Determining whether the project is worth conducting
4. Developing the initial (baseline) project schedule and budget
5. Getting approval for the project from a steering committee, where applicable, and launching
and communicating the project.

7. The specifications process isn't about how – it comes later when developing the technical
solution. The requirements phase is focused on the what of defining business requirements. To
identify the business require-ments, the analyst should be asking instead “what do the users
require (or want) from the new system?”
In short, before the requirements are known, the analyst is trying to devise a technical solution.
Whether the researcher is incompetent or intentionally trying to take a shortcut doesn't matter;
cutting short the process of the criteria review (or missing it completely) invariably leads to
threatened or failed programs.

8. The accurate and complete definition and voicing of system requirements is one of the most
difficult tasks of any enterprise. To assist conceptually, requirements are generally divided into
two categories – functional and non-functional. Functional requirements consist of the concrete
activities and services that make up a system, i.e., the inputs, processes, outputs and data
stores, and that are needed to meet the system improvement objectives. Nonfunctional
requirements refer to the behavioral attributes of the system, such as, performance factors such
as speed of operations and response time, cost of operations, ease of use, security controls,
quality management, documentation, etc. Specifications are typically presented in sketch or
table format.
It overview or table describes in its most basic format the inputs, procedures, outputs and data
stores required for each purpose of enhancement of the program. For a wide range of
methodologies, use cases, which were originally developed as a design technique with
object-oriented research, have become increasingly common use. Use cases address system
requirements by predicting the various business situations that arise and the solutions the
solution must provide.

9. Prioritizing requirements is an important safety measure of protection should the project slip
behind schedule or over budget. Prioritizing often lets stakeholders focus their attention on the
actual target. Earlier on in the process, during the criteria review phase, the stage at which the
specifications should be prioritized is rather than waiting until a project crisis occurs. Timeboxing
is a frequently used technique that divides the requirements into “chunks” or subsets that can be
developed and released in successive versions. The requirements are divided into two groups:
1) mandatory requirements, which are absolutely essential to meeting the system improve-ment
objectives and thus not ranked
2) desirable requirements, which are not absolutely essential and thus can be ranked. The first
subset, which is often termed version 1.0, generally contains only the mandatory requirements
group. The desirable requirements are then put into succeeding versions that can be developed
and released in six to nine month increments. One way to test whether a mandatory
requirement is truly mandatory is attempt to rank it. If it can be ranked, then it is really a
desirable require-ment, not a mandatory requirement.

10. While our work could be simpler if the scale became unchanged, in the real business
environment that is almost never the case. During the course of the project, improvements can
take place in the business environment, task and/or processes. Not only is scope inherently
dynamic, our understanding of the scope tends to change and evolve during the requirements
analysis process. It is therefore necessary to revisit the project plan at this stage to ensure that
any adjustments in the design or our interpretation of it are expressed in the schedule and
budget.
For many of the same causes, stakeholders feel almost always a need to incorporate or modify
specifications after the requirements review process. In view of this reality, a process of change
management is absolutely imperative, not only to track and document requests, but also to
specify the procedures for requesting changes and the criteria for evaluation. Absent a formal
process of handling transition, the project runs the risk of chaos in specifications.

14. The process of decision making can be viewed as a shift from the business concerns to the
technical concerns. That is reflected in the different stakeholder roles. As with other phases and
tasks, the system analyst generally acts as a facilitator in identifying solutions for candidates.
Device owners and consumers have their views and feedback but are not usually involved
explicitly in this mission. Of addition, their ideas should never be dismissed out of hand as the
owners and consumers, even if they may be technically naive; it is important to remember that
they are collaborators in the solution. System designers and builders will generally suggest a
number of potential solutions, based upon their areas of expertise and knowledge. Some
candidate solutions may also be limited and predefined, since the organization may require the
candidate solutions to be compatible with the organi-zation’s existing and/or approved
technology architecture. This is particularly true in public sector organizations and large private
sector companies.

15. There are at least four sets of criteria for your evaluation that will be used:
1.Technical feasibility, i.e., is it practical to design, build, implement and maintain this system
from a technical standpoint?
2.Operational feasibility, such as does it meet users’ needs and expectations, and if so, how well
does it do so? Do the users feel position about the candidate solution, and how much will it
change how they work?
3.Economic feasibility, such as do the one-time and ongoing costs compare fa-vorably to the
anticipated benefits?
4.Schedule feasibility, such as Can the candidate solution be developed and implemented within
the needed or desired timeframe?
In general, you would get input regarding the candidate solutions from a representative group of
stakeholders. The type of input would depend upon whether they are from the business or
technological side of the organization. Systems owners and users would typically provide input
regarding operational, economic and schedule feasibility, while systems designers and builders
provide input regarding the technical feasibility. Where appropriate, external experts may also
provide input. Comparisons should not be drawn between candidate solutions until each
individual candidate solution is analyzed and evaluated. The purpose is to avoid any premature
decision or bias. Most methodologies provide as a deliverable some type of feasibility analysis
matrix, so that decision makers are able to readily compare the different candidate solutions.
Modern Systems Analysis and Design, by Joseph S. Valacich & Joey F. George
Chapter 4

4.30 In value chain analysis, you must first understand each ac- tivity, function, and process
where value is or should be added. Next, determine the costs (and the factors that drive costs or
cause them to fluctuate) within each of the areas. After understanding your value chain and
costs, you can benchmark (compare) your value chain and associated costs with those of other
organiza- tions, preferably your competitors. By making these comparisons, you can identify
priorities for applying information systems projects.
It is an important project evaluation method that is widely used, but it can be costly and require
a lot of resources. Moreover, it should be dedicated to long-term goals and might be ineffective
in short-term.

4.32 Information systems costs continue to rise, the inability of systems to handle applications
that cross organizational boundaries, systems not addressing the critical problems of the
business as a whole nor supporting strategic planning applications, data redundancy and lack of
user confidence in the quality of data, out-of-control system maintenance costs, and lengthy
application backlogs are six reasons why improvements in the information systems project
identification and selection process are necessary.

4.33
Corporate strategic planning:
To make effective project selection decisions, a corporation must know where it is, where it is
going, and the path it will take to get there. Corporate strategic planning is based on this
premise. Corporate strategic planning can be viewed as a three step process: (1) current
enterprise, (2) future enterprise, and (3) strategic plan. During corporate strategic planning,
mission statements, statements of future corporate objectives, and strategies are developed.

Information strategic planning

Information strategic planning is an orderly means of assessing the information needs of an
organization, and defining the systems, databases, and technologies that will best satisfy those
needs. During Information strategic planning, current and future organization informational
needs will be modeled. Also, strategies and project plans to move the current information
system and technologies to their desired future state will be developed. Information strategic
planning looks at information systems and technologies in terms of how they can help the
business achieve its objectives defined during corporate planning. Information strategic
planning includes three key activities. The first activity involves assessing current information
system-related assets; the second step involves developing target blueprints of the resources; a
series of scheduled projects is defined in the third step.
4.35
A top-down planning approach is a generic information systems planning methodology that
attempts to gain a broad understanding of the information system needs of the entire
organization. Broader perspective, improved integration, improved management support, and
better understanding are four advantages.
As an example, the Martha Stewart Living company, owned and managed by lifestyle expert
Martha Stewart, utilizes the top-down approach — therefore, Stewart makes the decisions,
holds the most equity in the company, and drives the brand awareness due to her worldwide
popularity.