BUS 362 Lecture Notes - Lecture 5: Database Design, Computer Monitor, Flip Chart

63 views9 pages
Chapter 3: Requirements Determination
The Analysis Phase
The term analysis refers to breaking a whole into parts with the intent of understanding the parts’
nature, function and interrelationships.
Outputs of planning phase (system request, feasibility study, and project plan) = inputs into
analysis phase.
Systems analyst works with business users of new system to understand their need. So system
analysis can be broken down into 3 phases
oUnderstand the existing situation (as-is system)
oIdentify improvements
oDefine requirements for the new system (to-be system)
First step is skipped if no current system exists, if the current system and processes are irrelevant
to the future system, or if project team is using RAD/Agile development methodology in which as-
is system is not emphasized
oWaterfall and parallel development spend a lot of time understanding the as-is system and
capture improvements before identifying requirements
o RAD and agile methodologies (iterative, system prototyping, throwaway prototyping and
extreme programming) - focus on improvements and the to-be system requirements team
and devote little time investigating as-is systems
oReviewing existing systems can be valuable to the team
Critical thinking skills - important for analyst to understand key issues and develop new business
processes that are supported by information system technologies
Final deliverables of analysis phase - system proposal – includes requirements definition
statement, uses case, process model, and data model together with revised feasibility and work
plan.
System proposal presented to the approval committee in the form of a system walk-through to
explain system in detail – users, managers, and key decision makers identify needed changes.
oIf approved - system proposal components used as inputs in the design phase
oDeliverables from analysis phase = first step in the design phase of new system the line
between the analysis phase and the design phase is very blurry
The requirements determination is the most critical phase of the SDLC – primary cause of failure
oDuring the requirement determination the to-be system concept is easy to change since
little work has been done yet
oRAD and agile methodologies are effective – small batches of requirements identified and
implemented in incremental stages allowing the system to evolve over time
oV-model – tests and requirements defined at the same time (not last-minute process).
Requirements determination
Performed to transform the system request’s high-level statement of business requirements into
detailed, precise list of what the new system must do to provide value to business.
Requirements analysis
Key Steps in this Process:
1: Get User’s Definition of the ‘Ideal’ System
2: Modify this Definition to Accommodate Constraints
3: Trade Off Marginal Factors Against Added Costs
issues:
1: Targeting User’s Expectations
2: Preconceptions of the System Builders
3: Changing Environment Over Time
find more resources at oneclass.com
find more resources at oneclass.com
Unlock document

This preview shows pages 1-3 of the document.
Unlock all 9 pages and 3 million more documents.

Already have an account? Log in
What is a requirement?
Requirement – statement of what the system must do or what characteristics the new system
have
Requirements provide different perspectives:
oWhat the business needs (Business requirements) planning phase
Overall goal of the system
A business process.
E.g. handle payroll
oHow the system should be built (System requirements)design phase
A technical conversion of the business process.
E.g. access pay/time data for the current period, calculate net pay, automatically
direct deposit to pre-specified account, and update accounts
oWhat the users need to do (User requirements) analysis phase
What user needs to accomplish with the system?
oWhat the software should do to help the user complete a task? (Functional
requirements)
relates directly to a process the system has to perform or information it needs to
contain to help user complete a task
E.g. retain current price data and availability on all inventory items
oCharacteristics the system should have (Non-functional requirements)use in design
phase
Behavioral properties of a system (performance and usability)
Functional requirements
Process the system performs to support user task and/or information it provides user performing
a task.
oUser requirement = schedule client appointment
oFunctional requirement = find openings matching client availability, select desired
appointment, record appointment and confirm appointment.
Functional Requirements categories:
oProcess oriented – a process the system must do to perform
E.g. System must allow registered users to view their order history
oInformation-oriented – information a system must contain
E.g. The system must retain customer order history
Process models – explain relationship of functions/processes to system users, how
functions/processes relate to each other, how data is entered and produced by
functions/processes, and how functions/processes create and use stored data.
oClarify software components needed to accomplish the functional requirements.
Information-oriented functional requirements - define data that must be kept track to accomplish
the user tasks – defined in the data model.
User requirements and functional requirements identified in the analysis phase - flow to design
phase –more technical describing how system will be implemented.
Requirements in design phase - reflect developers’ perspective - called system requirements
describe how to create software product that will be produced
oAs the projects develops, requirements evolve from broad goals to detailed statements of
business capabilities the system should provide a technical statements of how these
capabilities will be implemented.
find more resources at oneclass.com
find more resources at oneclass.com
Unlock document

This preview shows pages 1-3 of the document.
Unlock all 9 pages and 3 million more documents.

Already have an account? Log in
Non-Functional requirements –quality attributes, design, and implementation constraints, and
external interfaces which a product must have
Operational – physical and technical operating environments
Performance – speed, capacity, and reliability needs
Security – access restrictions, needed safeguards
Cultural and Political – issues in the final system e.g. currency conversion
oNon-functional requirements - center stage in design phase - when decisions made about
user interface, hardware and software, and systems underlying architecture.
The process of determining requirements
Business and IT perspectives needed to define requirements during analysis phase.
Most effective approach is to have businesspeople and analysts work together to determine
requirements
Analyst should think about how to identify the sources for requirements from stakeholders
(project sponsor, project champions, all users of the system)
The analyst should consider how to produce the requirements from the stakeholders
oInterviews, questionnaires, observation, JAD and document anaysis
Determining requirements continues throughout analysis phase, and requirements evolve over
time as new requirements are identified as the project moves into later phases of the SDLC.
oKeep requirements list tight and focused – evaluate requirements that fit within scope
(importance, time and budget).
The requirements definition statement
A text report that lists functional and nonfunctional requirements in an outline format.
oUnique numbers for each requirement – easily track through entire development process.
oGrouped into function and non-functional
Classified further by type of requirement/business area
oSome requirements could be prioritized – rank importance
The purpose of the statement is to provide clear vision of what new system should do - defines the
scope of system.
Explain users expectations and to clarify discrepancies
Requirement elicitation techniques
Ensure current business processes and needs for system is understood before moving into design
– wrong requirements late in SDLC cause problems.
Requirements elicitation in practice
Side effects of the process of determining requirements include:
oBuilding political support for the project
oEstablishing trust between the project team and the users
Determine who is included in the process of determining requirements – Key stakeholders
Respect the time commitments participants make – make good use of elicitation techniques
a useful strategy for the analyst to employ is to begin requirements gathering by interviewing
senior managers to gain an understanding of the project and get the “big picture.” These
preliminary interviews can then be followed by document analysis and, possibly, observation of
business processes to learn more about the business domain, the vocabulary, and the as-is system.
More interviews may then follow to collect the rest of the information needed to understand the
as-is system.
Identifying improvements is commonly done with a JAD session
find more resources at oneclass.com
find more resources at oneclass.com
Unlock document

This preview shows pages 1-3 of the document.
Unlock all 9 pages and 3 million more documents.

Already have an account? Log in

Get access

Grade+
$10 USD/m
Billed $120 USD annually
Homework Help
Class Notes
Textbook Notes
40 Verified Answers
Study Guides
1 Booster Class
Class+
$8 USD/m
Billed $96 USD annually
Homework Help
Class Notes
Textbook Notes
30 Verified Answers
Study Guides
1 Booster Class