Systems Analysis Current Page

Information Systems Analysis
Current Events Discussions and Announcements

		Remember to check the Analysis Links Page for more information on specific topics, and the homework page for assignments. Copies of project reports from earlier semesters -- with comments -- are available.

The final exam.

Variations in interpretation of specifications (requires Powerpoint: you must "run show" and turn on speakers to appreciate)

The order of presentations on Monday, May 28 is

Day Class: Group C, Group B, Group A

Evening Class: Group A, Group D, Group E, Group C, Group B

Now that the groups in both classes have made their presentations on requirements, I will share them with both classes.

Day Class: Requirements presentation

Evening Class: Requirements presentation

From Modern Analyst.com, April 18, 2008

What are non-functional requirements?

Non-functional requirements are characteristics of a system or solution which describe non-behavioral characteristics or qualities of a system.

Whereas functional requirements describe the behaviors or functions of a system, the non-functional requirements generally describe those attributes which the system must have but which do not represent something an actor can do with the system.

Non Functional Requirements have also been called the 'ilities' because they can be expressed like this: usability, reliability, interoperability, scalability, extensibility, etc. Non-functional requirements are also commonly referred to as quality of service (QoS) requirements or service-level requirements.

In many instances non-functional requirements describe (are attributes of) functional requirements. For example: if a functional requirement of a system is "the system shall allow the customer to view current month's statement" a non-functional requirement which describes this need might be "the system shall generate the current month's statement in 30 milliseconds" or "the system shall store monthly statements for up to 12 months".

In other instances, non-functional requirements describe constraints on a system such as legal and regulatory constraints.

A simple test to determine if a requirement is functional or non-functional is to ask yourself if you can describe the requirement using the action of an actor or user of a system (think use cases and user stories). If the requirement can be easily described with a use case or user story then it is probably a functional requirement, otherwise it is most likely a non-functional requirement.

How do you discover and elicit non-functional requirements?

Different organizations have different methods and processes for eliciting and discovering non-functional requirements. Common ways of discovering non-functional requirements include:

1. Stakeholder goals, values, and concerns - Talk to the stakeholders! What a novel idea! ;-) The analyst must find out what is important to the stakeholders (including the users), what qualities are must have in order to achieve stated business and organizational goals. For example: must be able to create a new transaction in under 2 minutes. Also, find out what are the stakeholders worried about. For example: Users are afraid that the new system will be too slow (because the current one is).

2. Legacy system and/or existing platform constraints - the analyst takes a look at constraints dictated by the environment into which the new system must fit, the existing systems with which it must integrate, and the technical platform(s) it must use.

3. Competitive analysis of system qualities - additional non-functional requirements can be discovered by analyzing the qualities of competing systems. For example: how many users can the competing system support and do we need to do better?

4. Industry and market trends - try to understand the direction the industry or vertical market is taking and identify key trends. For example: What is the average annual growth of the industry in number of transactions? Do customers expect faster and faster response times?

5. Standard non-functional requirements templates and categories - in many organizations business analyst simply uses standard templates and categories in order to focus on and ask questions about each type of non-functional requirement (could be done using a questionnaire): usability, scalability, performance, availability, stability, extensibility, etc.

6. Pre-established trigger questions - many teams develop a set of trigger questions to be asked of the stakeholders and development team. For example:

* Documentation & Training

o What kind of documentation is required and who will be the users of the documentation?

o How quickly should a brand new user be up and running on the system?

o Is there a need for context sensitive help?

* Performance Characteristics

o Are there any speed, throughput, or response time constraints on the system?

o Are there size or capacity constraints on the data to be processed by the system?

o Do performance requirements vary by: time of day, day of the week, type of user, etc.?

* Error Handling and Extreme Conditions

o How should the system respond to input errors?

o Is there a need to track errors via a mechanism such as error logging?

o Are there expectations on reporting errors: per categories, by business channel, etc.?

* External Interfaces & Interoperability

o Is there data coming from (going to) external systems?

o Are there restrictions on the format or medium that must be used for input or output?

o How must the data exchange with external systems function: real-time, hourly, daily, etc.?

* System Modifications

o What parts of the system are likely candidates for later modification?

o What types of modifications are expected?

o How often do you expect the system will need to be modified?

* Security

o What data managed by the system must be secure?

o Who, when, where should be able to access the system?

* Disaster Recovery & Business Continuity

o How often will the system be backed up?

o Who will be responsible for the back up?

o What data must be saved in case of a disaster?

o How quickly after a major disaster must the system be up and running?

o What is the acceptable system downtime per 24-hour period?

How do you categorize non-functional requirements?

There are many different ways to categorize non-functional requirements depending on the type of system, project, organization, or preference.

Here are some common ways of categorizing requirements:

1. Qualities vs. Constraints

Qualities of a System: these are characteristics or properties of a system that the stakeholders care about. These are commonly sub-categorized as:

* Run-time Qualities: These are generally qualities which describe how well the functional requirements behave/are perceived when the system is being used:

o usability,

o configurability,

o supportability,

o correctness,

o availability and reliability,

o quality of service requirements: performance, response time, latency, etc.

o security,

o fault tolerance,

o scalability

* Development-time Qualities: These are qualities of the system, architecture, documentation, and design which have an impact on the effort, ease, and cost of maintaining and changing the system over time:

o localizability�ability to make adaptations due to regional differences

o modifiability or extensibility�ability to add (unspecified) future functionality

o evolvability�ability to change over time and to integrate and use new technologies

o composability�ability to compose systems from components

o reusability�ability to (re)use in future systems

Constraints of a System: these are characteristics of the pre-existing environment within which the new system or solution must operate, such as: legal and regulatory constraints, available development frameworks, target hardware, knowledge and skill of the development team, time and budget, etc.

2. Execution vs. Evolution

Execution requirements: Qualities a system must have which are observable at run time: security, usability, etc.

Evolution requirements: Qualities a system must have which address the nature and structure of the system and which permit a system to be evolved in the future: scalability, extensibility, etc.

3. Many categories: most organizations simply maintain a long list of non-functional requirement categories including but not limited to:

* Accessibility

* Audit and control

* Availability

* Certification

* Dependency on other parties

* Documentation

* Efficiency (resource consumption for given load)

* Effectiveness (resulting performance in relation to effort)

* Escrow

* Extensibility (adding features, and carry-forward of customizations at next major version upgrade)

* Infrastructure

* Legal and licensing issues

* Maintainability

* Operating constraints

* Performance / Response time

* Platform compatibility

* Price

* Quality (e.g. Faults Discovered, Faults Delivered, etc.)

* Reliability (e.g. Mean Time Between Failures)

* Resilience

* Resource constraints (processor speed, memory, disk space, network bandwidth etc. )

* Robustness

* Scalability

* Software, tools, standards etc.

* Stability

* Supportability

* Usability and User Experience

See also the following:

CASE Tools and the Productivity Paradox

A Comparison of Diagramming Tools

Entity Relationship Diagrams

The Process of Drawing E-R Diagrams

Guidelilnes for ER Diagrams

(3/3/08)

Now that the groups in both classes have made their presentations on diagrams, I will share them with both classes.

Day Class: presentation -- part 1, presentation -- part 2

Evening Class: presentation and use case diagram

Learn more about information overload issues.

The project management talk is now available.

More about IDEO. Also look at IDEO's website.

More about brainstorming pitfalls and best practices.

Night semester groups

Group A

Elizabeth Brown
Larry Robinett
India Thomas
Matt Ubdegrove

Group B

Maurice Hughes
Marawan Mohammed
Dayanand Thakur
Erin Thompson

Group C

Gidey Adebaby
David Doom
TJ Loh
Dede Tumbrink

Group D

Michael Bock
Irma Richardson
Christie Schillinger
Mark Thornhill

Group E

Shannon Jackson
Will Ly
Scott Sage
Louis Tang

Methodologies

Another view of the Systems Process

an outline of the process

modeling

learning about the system

flux in real systems

The class presentations for the two classes will be:

Day Class

28-Jan: Methodologies -- Sasan Rastegarlari and Eric Delisle

20-Feb: Diagrams -- Jon Tirjan, John Kaestner, and Nate Kettler

3-Mar: Questionnaires -- Chris Prewitt, Deidre Husten

12-Mar: Estimation -- no presentation

17-Mar: Feasibility -- Travis Clark, Garrett Jones, Ryan Butler

14-Apr: Prototyping -- Shere Stewart and Mike McBee

21-Apr: System Requirements -- Bruce Campbell, Kimberly Harris

Evening Class

28-Jan: Methodologies -- Irma Richardson and Mark Thornhill

25-Feb: Diagrams -- Taran Loh, Matt Ubdegrove, David Doom

3-Mar: Questionnaires -- Dede Tumbrink, Elizabeth Brown, Christie Schillinger

17-Mar: Estimation -- Erin Thompson, Larry Robinett, Shannon Jackson

17-Mar: Feasibility -- Scott Sage, Maurice Hughes, Mike Bock

14-Apr: Prototyping -- India Thomas, Daynand Thakur, Adebabay Gidey

21-Apr: System Requirements -- Louis Tang, William Ly, Marawan Mahmoud

Now that the groups in both classes have made their presentations, I will share them with both classes.

Day Class: presentation, notes 1, notes 2

Evening Class: presentation

We will break into groups and look at some creativity exercises today.

A man walked into a bar and asked the barman for a glass of water. They had never met before. The barman pulled a gun from under the counter and pointed it at the man. The man said "Thank you" and walked out. Why should that be so?

Two brothers were having a drink in a bar. Suddenly one of the brothers got into a heated argument with the barman. He pulled out a knife and, despite his brother's attempts to stop him, stabbed the barman in the chest. At the trial, he was found guilty of assault with a deadly weapon and grievous bodily harm. At the end of the trial, the judge said, "You have been found guilty of a vicious crime. However, I have no choice but to set you free." Why should that be so?

A traveller came to a small town. He had never visited it before, he knew no one there, and knew nothing about the town or its inhabitants. He needed a haircut. There happened to be two barbershops close to each other on the main thoroughfare -- the only barbershops in town. The man studied each of them with care. One shop was very neat and tidy. Everything about it was smart. The barber was sweeping away the last traces of hair from the floor while waiting for his next customer. The other barber's shop was very untidy. Everything looked rather run down and ramshackle. The scruffylooking barber within was lolling on a chair waiting for his next customer. Both shops charged the same amount for a haircut. After careful consideration, the traveler decided to go to the scruffy barber for his haircut. Why?

The resumes that we will consider to put individuals into groups will be available soon. The groups for this assignment only are:

Day Class

Group A
Bruce Campbell
Eric Delisle
Deirdre Huston

Group B
James Cook
Garrett Jones
Christopher Prewitt

Group C
Ryan Butler
John Kaestner
Sasan Rastegarlari

Group D
Travis Clark
Kimberly Harris
Shere Stewart

Group E
Nathan Kettler
Michael Mcbee
Jonathan Tirjan

Evening Class

Group A
Taranjeet Loh
William Ly
Larry Robinett
Louis Tang
Dayanand Thakur

Group B
Maurice Hughes
Scott Sage
India Thomas
Erin Thompson

Group C
Elizabeth Brown
Adebaby Gidey
Irma Richardson
Dede Tumbrink

Group D
Jeffrey Burton
David Doom
Christine Schillinger
Mark Thornhill

Group E
Michael Bock
Shannon Jackson
Marawan Mahmoud
Matthew Ubdegrove

Information

Measures of the value of information

alternate syllabus (an example of data, not information)

Information Comparison

Building Blocks of IS
(1/28/08)

From Ian I. Mitroff and Harold A. Linstone, The Unbounded Mind: Breaking the Chains of Traditional Business Thinking, New York: Oxford University Press, 1993.

Almost without exception, all who write about the new, global information age acknowledge that we are literally drowning in an overload and overabundance of information. Never before has humankind had access to so much, so quickly, and from every part of the globe. We have more data and information on every conceivable subject, yet less understanding at the same time. Data and information do not automatically lead to greater insight; they may now travel at the speed of light, but understanding and wisdom do not.

There is also common agreement that "data," "information," and "knowledge" are not the same, even though they are often -- wrongly so -- used interchangeably. Their differences are often as unclear to the experts as to the layperson.

One aspect above all else is especially disturbing. It is the strong, taken-for-granted assumption that agreement between the monumental and voluminous databases that both government and businesses are constantly producing will eventually result, and further that agreement itself is fundamentally desirable. -- p.20

In the end, the most general conclusion is "seek agreement or consensus but do not trust them fully." Agreement and consensus are important in reaching conclusions and in achieving the necessary support to carry out complex, important policies. However, as with all things human, they cannot be followed blindly. Nor are they the ultimate consideration for deciding all important questions. -- p. 37

Finally, we can state some rules of thumb ....

·Seek the obvious, but do everything in your power to challenge and even ridicule it.

·Question all constraints. The most limiting constraints in building a model or a representation of a problem are usually imposed not by the problem itself but by the mindset of the problem solver.

·Challenge as many assumptions about the problem and the model as possible. Remember that what seems self-evident to the problem formulator is not always evident to others.

·Question the scope or the definition of a problem or model. Frequently what is omitted from the statement of a problem or model is more important than what is included.

·Question whether a problem is to be "solved," "resolved," or "dissolved." There are important differences between "solving," "resolving," or "dissolving" a problem. They are not necessarily the same. To "solve" a problem means to produce an exact or optimal solution to it. To "resolve" a problem means to seek a solution that is "good enough." On the other hand, to "dissolve a problem is to realize that there may be some other problem that is more important to focus one's attention on. The old or initial problem may still exist but may not be as important in the broader scope of things.

·Finally question the logic itself. Being logical and being right are not always the same. The more logical a solution to a complex problem sounds, the more strongly it deserves to be challenged. -- p. 47-48

(1/28/08)

We must always look for the unintended consequences in systems analysis. (1/28/08)

Systems analysis defined: View this video. Seriously, view this video to talk about soft systems methodologies. (1/28/08)

The previous edition of your textbook had a chapter entitled "Succeeding as a Systems Analyst." It is available here with permission of the publisher. (1/28/08)

Standish Report Results

Resolution of Projects

Resolution of Projects, 1994-2004

Cost Overruns

Cost Overruns, 1994-2004

Top Ten Reasons for Success

CHAOS Report: 1994

(1/14/08)

An example consultant's analysis report: Strider and Cline evaluate UM's implementation of PeopleSoft. (1/14/08)

Systems Analysis

What Does A Systems Analyst Really Do?

What is Systems Analysis

Systems Development Life Cycle

Process v. Data Orientation

Different Types of Systems

Stage Deliverables

Deliverables

More about Deliverables

Agile Methods

(1/14/08)

Think about the skills associated with systems analysis. One of the items in the list is "systems thinking." We will look at the definition of a System and think about what Systems Thinking means. (1/14/08)

For more information about the tasks necessary for Systems Analysis, visit some of the sites on the Analysis Links page. In particular, visit the What Does A Systems Analyst Really Do? and the Systems Analysis Want Ads pages, and the Systems Development Life Cycle page. (1/14/08)