People: Analysis and Requirements COMP 101 Computational Thinking and Design Thursday, October 30,...
-
Upload
anabel-ward -
Category
Documents
-
view
212 -
download
0
Transcript of People: Analysis and Requirements COMP 101 Computational Thinking and Design Thursday, October 30,...
People:Analysis and Requirements
COMP 101Computational Thinking and Design
Thursday, October 30, 2014
Carolyn SeamanSusan Martin
University of Maryland, Baltimore County
Systems Analysis: What is it?
The systematic study of an existing situation (in a business, organization, social context, or scientific environment),
identification of problems and opportunities, and specification of the requirements for the solution.
Problem
Solution
What is the problem, really?
Is this problem worth solving?
What are the constraints on the solution?
What are the implications of fixing this?
Systems Analysis: Why is it?
Many information/computing systems fail, because they are:· insufficiently reliable· insufficiently usable· not what the users wanted· incompatible with other systems
SA addresses all but the first problem
SA is also a long-term approach to ensure the overall effectiveness of IT (software, hardware, and other components) in the organization
Systems Analysis: Who is it?
A systems analyst studies the computing problems and needs of an organization to determine how to best solve its problems and provide improvements using information technology. improved business processes improved information systems improved computer applications
Three major roles: consultant (outsider) supporting expert (insider) agent of change (shaker)
The Systems Analyst as the Bridge Person
SA
USERSDeveloper
sEngineers
Diagnoses problemsConfigure solutions
Tests new technology
Determines requirements
Designs new technology
The Systems Analyst as Aunt Marie
I have an Aunt Marie. She always remembers: To bring the bottle opener when we go on a picnic To bring the directions when we go on a trip To bring matches when we have a campfire
When Aunt Marie’s not there, we often forget things like this.
A Systems Analyst is like Aunt Marie – they always think of the things other people overlook, e.g. The political implications of a new information system The physical environment in which a new application will be
used The larger process in which a new piece of technology will be
embedded The constraints of the users of a new system The costs and benefits of a new technology development
Skills of a Systems Analyst
Analytical
Technical
Business
Management
Interpersonal
Ethical
Types of Analysts
Systems Analyst
Business Analyst
Infrastructure Analyst
Change Management Analyst
Project Manager
Systems Thinking
Nine system characteristics:- components- interrelationships between components- boundary- purpose- environment- interfaces- input- output- constraints
Systems Thinking (cont.)
Four system conceptsdecompositionmodularitycouplingcohesion
Systems Thinking (cont.)Advantages of systems thinking:
- allows you to think about an organization, a process, a program, etc. at a higher, more abstract level
- reveals problems that are obscured by physical details
- abstractions are easier to manipulate- promotes creativity
Assessing FeasibilityNot all solutions to a problem are feasible
Technical feasibility- Is technology available or are we able to develop it?- Compatibility with existing systems- Availability of expertise
Economic feasibility- Is the payoff worth the investment?- Do we know how much it will cost?
Organizational feasibility- Are there other obstacles to project success?- Stakeholders - political and legal issues- Strategic alignment- Schedule
Outcome of Feasibility Analysis
Risks lists of risk factors and eventshighest risks include more information - potential
loss, preventive actions, mitigating actions
Constraints limitations that the project has to live withusually schedule and budget, sometimes technical
or legal
Risks and constraints are then used to make design decisions
What is a Requirement?A statement of
One thing the system must do (functional requirements), or
One characteristic the system must have (nonfunctional requirements)
Business/organizational requirements – from the user’s perspective
Systems requirements – from the designer’s perspective
Examples of RequirementsFunctional requirements:
• When the cruise control systems is “on”, if the driver presses the “set” button, the current speed is captured and that speed is maintained until the user hits the brake or the accelerator, or until the cruise control system is turned “off”.
• If the driver presses the accelerator while the cruise control system is controlling the speed, the speed is allowed to increase as long as the driver is pressing the accelerator, but returns to the maintained speed when the user releases the accelerator.
Nonfunctional requirements:
• While the cruise control system is “on”, reaction time to all driver actions must be less than 0.1 seconds.
• At least 80% of all test drivers must be able to use the cruise control system without error after driving with it for no more than 20 minutes.
Requirements Definition Document
Organized as a numbered list of requirements Groups functional and nonfunctional requirements Often other subcategories
Created early in analysis to capture what the current system does that we want to keep
Updated after analysis to specify what new things we want the new system to do
Used during design and development to guide design decisions.
Used during testing to determine how the system should behave.
Requirements Gathering Techniques
Interviewing
Questionnaires
Observation
Documents
Joint Application Design (JAD)
Prototyping
The Desk Set1957 movie starring Spencer Tracy and
Katherine Hepburn
Not their best work
BUT… a really good example of systems analysis gone horribly wrong
Prototype DemoNext Thursday, Nov. 6, in class
Each team has 8 minutes3 minutes introduction3 minutes demo2 minutes questions
Use your own laptop – make sure it has a HDMI port
Everyone on the team must participate
Dress professionallySomewhere between suit and tie, and shorts and t-shirt
Required ContentIntroduction
Introduce team membersDesign decisions – architecture and interfaceProblems and successesWhat you still need to work on
Demo Input and OutputDoes not need to run all the way through 15 weeks
QuestionsAny team member can be called on to answer any
question
ProfessionalismWhen presenting
Move aside and pay attention when another team member is speaking
Transition professionally between speakersTreat each other with respectDo not interrupt or contradict a team member
When watchingPay attention – no devices!!Ask questions for information, not to make anyone
uncomfortableThis is also part of your grade
GradingPresentation 35%
10% Presentation quality 5% Everyone participated and behaved professionally
during all presentations 10% Demo included all working functionality 10% Demo included clear explanations of any missing
functions
Code 45% 10% each input, calculations, output 15% Coding standards
Document 20% 10% Description of design changes 10% Description of bugs and work still to do
Giving Effective Presentations
Rule
Know what on earth you’re doing up there!
Rule #2: Know what you want to say
Rule #3: Know your audience
Rule #4: Know how long you have
Rule #2: Know What You Want to Say
Just reciting a series of statistics or showing a bunch of numbers is not interesting to most people
You should give enough detail to get your interesting ideas and observations across, but not enough to lose your audience
They want to hear what you learned that was interesting and why they should care
Whatever you do, don’t just read your slides!
Rule #3: Know Your Audience
You’re talking to the other students (not me)
You need to be sure you’re explaining each new idea clearly
The most important thing is to emphasize what you’ve discovered and why they should care!
Rule #4: Know How Long You Have
How long is the talk? Are questions included?
A good heuristic is 1-2 minutes per slide ...but it depends a lot on the content of those slides!
If you have too many slides, you’ll skip some or—worse—rush desperately to finish. Avoid this temptation!!
Almost by definition, you never have time to say everything about your topic, so don’t worry about skipping some things!
Unless you’re very experienced giving talks, you should practice your timing