Input, Output, and User Interface Design

---

Input Design

Management and users make important decisions based on system outputs. These outputs are produced from data that is either input or retrieved from databases. And any data in the databases must have been first input.Today most inputs are designed by rapidly constructing prototypes. These prototypes may be simple computer-generated mock-ups, or they may be generated from prototype database structures such as those developed for Microsoft Access. These prototypes are rarely fully functional. They won't contain security features, data editing, or data updates that will be necessary in the final version of a system. Furthermore, in the interest of productivity, they may not include every button or control feature that would have to be included in a production system.

During requirements analysis, inputs were modeled as data flows that consist of data attributes. Even in the most thorough of requirements analysis, we will miss requirements. Input design may introduce new attributes or fields to the system. This is especially true if output design introduced new attributes to the outputs—the inputs must always be sufficient to produce the outputs. Inputs can be classified according to two characteristics: (1) how the data is initially captured, entered, and processed and (2) the method and technology used to capture and enter the data.

---

Output Design

Outputs are the most visible component of a working information system. they are often the basis for the users' and management's final assessment of the system's value. During requirements analysis, we defined logical output requirements. During decision analysis, we are considered different physical implementation alternatives.

Most outputs are designed by rapidly constructing prototypes. These prototypes may be simple computer-generated mock-ups with dummy data, or they may be generated from prototype databases such as Microsoft Access, which can be rapidly constructed and populated with test data. These prototypes are rarely fully functional. They won't contain security features or optimized data access that will be necessary in the final version of a system. Furthermore, in the interest of productivity, we may not include every button or control feature that would have to be included in a production system.

During requirements analysis, outputs were modeled as data flows that consist of data attributes. Even in the most thorough of requirements analysis, we will miss requirements. Output design may introduce new attributes or fields to the system.Outputs can be classified according to two characteristics: (1) their distribution and audience and (2) their implementation method.

One way to classify outputs is according to their distribution inside or outside the organization and the people who read and use them. Internal outputs are intended for the system owners and system users within an organization. They only rarely find their way outside the organization. Internal outputs support either day-to-day business operations or management monitoring and decision making.
The opposite of internal outputs is external outputs. External outputs leave the organization. They are intended for customers, suppliers, partners, and regulatory agencies. They usually conclude or report on business transactions. Examples of external outputs are invoices, account statements, paychecks, course schedules, airline tickets, boarding passes, travel itineraries, telephone bills, purchase orders, and mailing labels.

---

Interface Design

we integrate output and input design into an overall user interface that establishes the dialogue between users and computer. The dialogue determines everything, from starting the system or logging into the system, to setting options and preferences, to getting help. And the presentation of the outputs and inputs is also part of the interface. We need to examine the screen-to-screen transitions that can occur. In client/server applications (e.g. network-based Windows) and Web applications (e.g., Internet- or intranet-based browsers), the user has many alternative paths through menus, hyperlinks, dialogues, and the like. This makes for very accommodating and friendly user interfaces, but it greatly complicates design and programming.

Today most user interfaces are designed by rapidly constructing prototypes. These prototypes are generated using rapid application development environments such as Microsoft's Visual Studio. These prototypes are rarely fully functional, but they do contain enough functionality to demonstrate the interface. For example, a help system prototype may be functional to the extent that it calls up a few sample screens to demonstrate levels of assistance. Or a security system might have just enough functionality to demonstrate representative log-in errors even though it is not actually authenticating users. When we get to the construction phase of the life cycle, programmers and analysts will complete the functionality

User Interface Technology

Most of today's user interfaces are graphical. The basic structure of the graphical user interface (or GUI) is provided within either the computer operating system or the Internet browser of choice. In client/server information systems, the user interface client is implemented to execute within the PC operating system. In Internet and intranet information systems, the user interface is implemented to execute within the PC's Web browser.

Feasibility Discovery, Design, and Architecture

---

Feasibility

Feasibility is the measure of how beneficial or practical the development of an information system will be to an organization. Feasibility analysis is the process by which feasibility is measured.The scope and complexity of an apparently feasible project can change after the initial problems and opportunities are fully analyzed or after the system has been designed. Thus, a project that is feasible at one point may become infeasible later.

Figure below shows feasibility checkpoints during the systems analysis phases of our life cycle. The checkpoints are represented by red diamonds. The diamonds indicate that a feasibility reassessment and management review should be conducted at the end of the prior phase. A project may be cancelled or revised at any checkpoint, despite whatever resources have been spent.

The first feasibility analysis is conducted during the scope definition phase. At this early stage of the project, feasibility is rarely more than a measure of the urgency of the problem and the first-cut estimate of development costs. It answers the question, Do the problems (or opportunities) warrant the cost of a detailed study and analysis of the current system? Realistically, feasibility can't be accurately measured until the problems (and opportunities) and requirements are better understood.After estimating the benefits of solving the problems and opportunities, analysts estimate the costs of developing the expected system. Experienced analysts routinely increase these costs by 50 to 100 percent (or more) because experience tells them the problems are rarely well defined and user requirements are typically understated.
The next checkpoint occurs after a more detailed study and problem analysis of the current system. Because the problems are better understood, the analysts can make better estimates of development costs and of the benefits to be obtained from a new system. The minimum value of solving a problem is equal to the cost of that problem.
The next checkpoint of the current system is decision analysis.The decision analysis phase represents a major feasibility analysis activity since it charts one of many possible implementations as the target for systems design. Problems and requirements should be known by now. During the decision analysis phase, alternative solutions are defined in terms of their input/output methods, data storage methods, computer hardware and software requirements, processing methods, and people implications.

Six Tests for Feasibility

• Operational feasibility is a measure of how well a solution meets the identified system requirements to solve the problems and take advantage of the opportunities envisioned for the system.
• Cultural (or political) feasibility is a measure of how people feel about a solution and how well it will be accepted in a given organizational climate.
• Technical feasibility is a measure of the practicality of a specific technical solution and the availability of technical resources and expertise to implement and maintain it.
• Schedule feasibility is a measure of how reasonable the project timetable is.
• Economic feasibility is a measure of the cost-effectiveness of a project or solution.
• Legal feasibility is a measure of how well a solution can be implemented within existing legal and contractual obligations.

---

System Design

Once the analysis is complete and the requirements are captured, the question becomes one of how to best provide a solution. This leads to the build or buy question, which can be very complex. Some questions to ask when making this analysis should include the following:

• Will the software (whether built or bought) meet the needs as defined in previous activities?
• Can the software be fully integrated with existing systems?
• Will the cost of the complete system (including hardware and software) be manageable from a budgeting perspective?
• Will the software be able to provide specialized functions that may be strategic in nature?
• Does the system meet existing system directives and strategies?
• Will additional labor be needed for customization?
• Are existing platforms workable with the new software?
• Is the architecture stable?
• Does the architecture risk immediate antiquation?
• Are support resources available for the anticipated demand?

By answering these questions, system architects are more likely to uncover system incompatibilities before they occur, in addition to helping make the build or buy decision.

---

Architecture

A system architecture specifies the technologies to be used to implement one or more information systems. It serves as an outline for detailed design, construction, and implementation. The highest level plan for solving systems problems is the system architecture.The system architecture is composed of all the systems and subsystems that make up the entire information system of the organization. This includes databases, application logic, and decision support systems.
To develop this high-level plan, several steps are required.

• Distinguish between operational and decision-support applications
• Decompose large systems into layers and partitions. This simply means to look for subsystems and separate them from the overall system logically
• Separate application logic from user interfaces
• Treat abstractions as real: This design principle means to move logic into data (to make the abstract real)
• Maintain a balance between the roles of the database management system and programming languages
• Consider the major interfaces to users and other systems

Event Diagrams, System Data Flow Diagram and Physical ERD

---

Event Diagrams

A data flow diagram for a single event handler and the agents and data stores that provide inputs or receive outputs. An event diagram is a context diagram for a single event. It shows the inputs, outputs, and data store interactions for the event. By drawing an event diagram for each process, users do not become overwhelmed by the overall size of the system. They can examine each use case as its own context diagram.Before drawing any event diagrams, you may find it helpful to have a list of all the data stores available.The simplicity of event diagramming makes the technique a powerful communication tool between users and technical professionals.Here is an example of an Event diagram.

Most event diagrams contain a single process - the same process that was named to handle the event on the decomposition diagram. For each event, illustrate the following:

• The inputs and their sources. Sources are depicted as external agents. The data structure for each input should be recorded in the repository.
• The outputs and their destinations. Destinations are depicted as external agents. The data structure for each output should be recorded in the repository.
• Any data stores from which records must be "read" should be added to the event diagram. Data flows should be added and named to reflect what data is read by the process.
• Any data stores in which records must be created, deleted, or updated should be included in the event diagram. Data flows to the data stores should be named to reflect the nature of the update.

---

System Data Flow Diagrams

System data flow diagram illustrates how data is processed by a system in terms of inputs and outputs. As its name indicates its focus is on the flow of information, where data comes from, where it goes and how it gets stored.System data flow diagrams are easier to understand by technical and non-technical audiences. It can provide a high level system overview,complete with boundaries and connections to other systems and a detailed representation of system components.

---

Logical and Physical ERD

Entity relationship diagram (ERD) represents a detailed picture of the entities needed for a business. In forward engineering, ERD will be transformed into a relational database eventually. There are two types of ERD - Logical and Physical. They are used in different stages of development, and are inter-related.Logical ERD models information gathered from business requirements. Entities and relationships modeled in such ERD are defined around the business's need. The need of satisfying the database design is not considered yet.
Physical ERD represents the actual design of database. It deals with conversion from logical design into a schema level design that will be transformed into relational database.Logical ERD is treated as base, refinement occurs by defining primary keys, foreign keys and constraints. Sometimes, relationships need to be resolved by introducing additional tables, like a Linked table for a many to many relationship.

Data Modeling

---

Data Modeling

Data modeling is the analysis of data objects that are used in a business or other context and the identification of the relationships among these data objects. Data modeling is a first step in doing object-oriented programming.Data modeling is the formalization and documentation of existing processes and events that occur during application software design and development. Data modeling techniques and tools capture and translate complex system designs into easily understood representations of the data flows and processes, creating a blueprint for construction and/or re-engineering. The data model in the analysis phase is called the context data model or logical entity relationship diagram (LERD).
Here is an example of context data diagram.

Requirements Discovery Methods and Process Modeling

---

Requirements discovery is the process and techniques used by systems analysts to identify or extract system problems and solution requirements from the user community.

The Requirements Discovery Process

• Requirements Planning
• Requirements Elicitation
• Requirements Analysis & Documentation
• Requirements Verification & Review
• Requirements Validation & Acceptance
• Requirements Change Management

---

Fact-finding

Fact-finding is a technique that is used across the entire development cycle, but it is extremely critical in the requirements analysis phase.It is also called information gathering or data collection.Tools, such as data and process models,document facts, and conclusions are drawn from facts. Fact Finding. Once fact-finding has been completed, tools such as use cases, data models, process models, and object models will be used to document facts, and conclusions will be drawn from the facts.During fact-finding, systems analysts often come across or analyze information that is sensitive in nature.Effective fact-finding techniques are crucial to the development of systems projects.
Fact-finding is most crucial to the systems planning and systems analysis phases.It is during these phases that the analyst learns about the vocabulary,problems,opportunities,constraints,requirements,and priorities of a business and a system.During systems design,fact-finding becomes technical as the analyst attempts to learn more about the technology selected for the new system.

Four common fact-finding techniques

• Sampling of existing documentation,forms, and databases.
• Research and Internet site visits.
• Observation of the work environment.
• Questionnaires

---

Context Data Flow Diagram

Context Diagrams and Data-Flow Diagrams were created for systems analysis and design.It is a graphical visualization of the movement of data through an information system. The Context Diagram shows the system under consideration as a single high-level process and then shows the relationship that the system has with other external entities (systems, organizational groups, external data stores, etc.).

A sample Context Diagram


Some of the benefits of a Context Diagram are:

• Shows the scope and boundaries of a system at a glance including the other systems that interface with it
• No technical knowledge is assumed or required to understand the diagram
• Easy to draw and amend due to its limited notation
• Easy to expand by adding different levels of data flow diagrams
• Can benefit a wide audience including stakeholders, business analyst, data analysts, developers

Project Management and Systems Analysis

---

Project management

Project management is the process of scoping, planning, staffing, organizing, directing, and controlling the development of an acceptable system at a minimum cost within a specified time frame.

There are three constraints that projects need to be delivered under. They are time, cost, and scope. These three constraints will determine the quality of the product delivered. Each constraint does have an effect on the other. For instance, if the scope or requirements of the project grow larger, then the cost of the project most likely will increase and the time it takes to finish the project will be longer.

Project management is being able to apply the knowledge you have learned, apply the skills you have developed, use the tools you have acquired, and apply the experience you have gained.

---

Systems Analysis

Systems Analysis is a problem-solving technique that decomposes a system into its component pieces for the purpose of studying
how well those component parts work and interact to accomplish their purpose.

Systems analysis is driven by the business concerns of system owners and system users. Hence, it addresses the knowledge, process and communications building blocks from system owners' and system users' perspectives. The Systems Analysts serve as facilitators of systems analysis. The documentation and deliverables produced by systems analysis tasks are typically stored in a repository. A repository is the a location (or set of locations) where systems analysts, systems designers, and system builders keep all of the documentation associated with one or more systems or projects.

---

System Analysis Phases

There are five systems analysis phases.

Scope Definition Phase

The scope definition phase is the first phase of the classic systems development process. The entire phase should not exceed two or three days for most projects One of the most important tasks of the scope definition phase is establishing an initial baseline of the problems, opportunities, and/or directives that triggered the project.

Problem Analysis Phase

The problem analysis phase provides the analyst with a more thorough understanding of the problems, opportunities, and/or directives that triggered the project. The problem analysis phase answers the questions, Are the problems really worth solving? and Is a new system really worth building?.

Requirements Analysis Phase

The requirements analysis phase defines the business requirements for a new system.The requirements analysis phase answers the question, What do the users need and want from a new system?. The requirements analysis phase is critical to the success of any new information system.

Logical Design Phase

The logical design phase further documents business requirements using system models that illustrate data structures, business processes, data flows, and user interfaces. In a sense, the analyst validates the requirements established in the previous phase. In this phase, the analyst draws various system models to document the requirements for a new and improved system.

Decision Analysis Phase

In the decision analysis phase, it is necessary to identify candidate solutions, analyze those candidate solutions, and recommend a target system that will be designed, constructed, and implemented. The tasks in this phase includes (1) identify candidate solutions,
(2) analyze candidate solutions, (3) compare candidate solutions, (4) update the project plan, and (5) recommend a system solution.

Systems Analysis, Design Methods and Development

---

Information system

- an arrangement of people, data, processes, and information technology that interact to collect,
process, store, and provide as output the information needed to support an organization.

Information technology

- a combination of computer technology (hardware and software) with telecommunications
technology (data, image, and voice networks)

Stakeholder

- any person who has an interest in an existing or proposed information system.
Stakeholders may include both technical and non-technical workers. They may also include both internal and external workers.

System analysis

- the study of a business problem domain to recommend improvements and specify the business
requirements and priorities for the solution.

System designer

- a technical specialist who translates system users' business requirements and constraints
into technical solutions. She or he designs the computer databases, inputs, outputs, screens, networks,
and software that will meet the system users' requirements.

System analyst

- a specialist, who study the problems and needs of an organization to determine how people,
data, processes, and information technology can best accomplish improvements for the business.

---

Where Do Systems Analysts Work?

---

Data

- raw facts about people, places, events, and things that are of importance in an organization.
Each fact is, by itself, relatively meaningless.

Information

- data that has been processed or reorganized into a more meaningful form for someone.
Information is formed from combinations of data that hopefully have meaning to the recipient

Knowledge

- data and information that are further refined based on the facts, truths, beliefs,
judgements, experiences, and expertise of the recipient. Ideally information leads to wisdom.

Object-oriented analysis and design

- a collection of tools and techniques for systems development
that will utilize object technologies to construct a system and its software.

Creeping commitment

- a strategy in which feasibility and risks are continuously re-evaluated
throughout a project. Project budgets and deadlines are adjusted accordingly.

Feasibility

- a measure of how beneficial the development of an information system would be to an organization.

---

SDLC

There are six phases in every Software development life cycle model:

1. Requirement gathering and analysis
2. Design
3. Implementation or coding
4. Testing
5. Deployment
6. Maintenance

1) Requirement gathering and analysis:

Business requirements are gathered in this phase. This phase is the main focus of the project managers and stake holders.
Meetings with managers, stake holders and users are held in order to determine the requirements like; Who is going to use
the system? How will they use the system? What data should be input into the system? What data should be output by the
system? These are general questions that get answered during a requirements gathering phase. After requirement gathering
these requirements are analyzed for their validity and the possibility of incorporating the requirements in the system to
be development is also studied.Finally, a Requirement Specification document is created which serves the purpose of guideline
for the next phase of the model.

2) Design:

In this phase the system and software design is prepared from the requirement specifications which were studied in the first
phase. System Design helps in specifying hardware and system requirements and also helps in defining overall system architecture.
The system design specifications serve as input for the next phase of the model.

3) Implementation / Coding:

On receiving system design documents, the work is divided in modules/units and actual coding is started. Since, in this phase
the code is produced so it is the main focus for the developer. This is the longest phase of the software development life cycle.

4) Testing:

After the code is developed it is tested against the requirements to make sure that the product is actually solving the needs
addressed and gathered during the requirements phase. During this phase unit testing, integration testing, system testing,
acceptance testing are done.

5) Deployment:

After successful testing the product is delivered / deployed to the customer for their use.

6) Maintenance:

Once when the customers starts using the developed system then the actual problems comes up and needs to be solved from time to
time. This process where the care is taken for the developed product is known as maintenance.

---

There are various Software development models or methodologies.
1) Waterfall Methodology

The Waterfall Model was first Process Model to be introduced. It is also referred to as a linear-sequential life cycle model.
It is very simple to understand and use. In a waterfall model, each phase must be completed fully before the next phase can begin.
This type of model is basically used for the project which is small and there are no uncertain requirements. At the end of each phase,
a review takes place to determine if the project is on the right path and whether or not to continue or discard the project. In this
model the testing starts only after the development is complete. In waterfall model phases do not overlap.

---

2) RAD (Rapid Application Development) Methodology

Rapid application development (RAD) - a system development strategy that emphasizes speed of development through extensive user
involvement in the rapid, iterative, and incremental construction of a series of functioning prototypes of a system that eventually
evolves into the final system (or a version). RAD is most popular for small- to medium-size projects.

The basic ideas of RAD are:

To more actively involve system users in the analysis, design, and construction activities.
To organize systems development into a series of focused, intense workshops jointly involving SYSTEM OWNERS, USERS, ANALYSTS, DESIGNERS, and BUILDERS.
To accelerate the requirements analysis and design phases through an iterative construction approach.
To reduce the amount of time that passes before the users begin to see a working system.