New Page 1

System Analysis

What is system analysis?

A summary of the overall flow of work within an organization. A statement about whether a software system is needed and where it might fit in.

To say this another way: Don't just start programming. Figure out what software (if any) needs to be written and why.

System analysis is like city planning.

Suppose you were creating a complete new town from scratch.

What would be in the city? Would it have everything everyone wanted, or just some features? Would you rely on towns nearby for some things?

Where would the houses be? Do you even need houses?

Would there be one downtown, or many smaller neighborhoods?

(We will use the town/building analogy throughout the software development process.)

An example of system analysis....

A friend of mine had a bed and mattress business. When customers bought a bed, they usually wanted it delivered. My friend had a truck to make the deliveries.

The problem -- He often forgot to make a delivery, or lost the address, or over-committed the truck to do too much in one afternoon.

My friend asked what kind of software I could write (or buy) to help him with this problem.

What do you think? Class input.

My suggestion to my friend -- Put a large paper calendar on the wall behind the cash register. Write down all the deliveries here. When someone buys a bed, just turn around and see when the delivery can be made. He won't overbook, or lose the address, or forget the order. The delivery driver can look at the calendar each morning.

The moral -- Take time to understand the entire organization or process, to see if any software is needed, and (if so) what it should do.

Explain the pictures 10.1, 10.2 and 10.3 in SEPA

System analysis is nested.

For business analysis, you first study the whole organization. Then one department. Then the role of computers within the department, then one computer system, the one part of one system, etc.

For product analysis, you start with the whole product, then each part of the product, then the software for one part, then the details of that software, etc.

The same nesting applies to requirements analysis, technical design, test plans, documentation, etc. All should start at the big picture level, with successive finer detail as the project develops.

Modeling and simulation. (only covered briefly in the text)

What is it? (A way to test a program, or system, before creating it.)

Examples? (Wind tunnel testing of aircraft models. Queuing theory testing of networking strategies.)

What are its advantages? (Can sort through designs quickly, without months of programming for each.)

What are its disadvantages? (Modeling is not reality. No guarantee that the exercise leads to a good system.)

What is the best method of all for system analysis? (UNDERSTAND and THINK.)

Do we need system analysis for our programming projects? (No. We are artificially assuming that this software needs to be written, so we are skipping this step.)

Software Requirements Analysis

Requirements analysis is the next level of detail after systems analysis. We have decided that we want to write a software system, now what (in detail) should the software do?

Requirements analysis does not describe the inner workings of the software -- language, compiler, variables. It describes what the software will DO as seen from the outside.

RA is like planning the features of one house within a city. (But not drawing a detailed blueprint.)

How many people will live in the house?

Do you love to cook and spend a lot of time in the kitchen?

Do you like to garden?

Does it need a backyard for kids to play in, or is there a park right across the street?

Does it need a well, or is there town water?

These questions only make sense within the context of a whole city.

Would you seriously begin to build a house without planning what needs it will meet? No. And you should not begin any serious programming project without some degree of requirement analysis.

Benefits of doing a software requirements analysis...

You are far more likely to write a program that users will use.

You can write software that works with, and takes advantage of, the rest of the system.

You can weed out large operational bugs as you refine the requirements.

Can use the RA to drive the time and people estimates.

Problems with doing an RA...

They can be very time consuming and tedious. (It is tempting to just start programming without an RA.)

Example of my client who is stuck in requirements phase for 12 months.

Users don't know, or can't say, what they want.

The requirements change while you are writing the software.

Example of how hard it is to get good requirements...

Lead Management System at local manufacturing company

Overview of what the system does. Lead cards that are mailed in -- name, address, publication and date, info requested, salesperson for territory.

The requirements were pretty clear (and written down).

I created the software, based on the requirements I was given by the person paying for the project.

I delivered the system and held a meeting to show it to 6-8 users. They said "Oh no!" There were two salespeople for each territory (which I had not been told).

I added this feature, delivered it, and held another demonstration meeting. They said "Oh no!". Each salesperson should see only their own leads, even within the same territory. (No security within the company had been mentioned.) This was a big change.

I added this feature, delivered it, and held another demonstration. They said "Oh no!" The data had to flow to an existing system. Another big change.

I added this, etc, etc.

Morals... The planning process did not include all the necessary people. Users had unspoken assumptions, which everyone knew, except for me. (Perhaps I should have used a planning method that brought out these assumptions.)

But, even with these problems, an RA of some type is worth the effort.

There are many detailed methods of gathering requirements from users and writing requirement analysis. Some of these are discussed in RD chap 11. Any of these (or several) would be a good topic for extra credit or a team talk.

Feature Set Control (RD 14)

When you plan a house, of course you would like to have everything. It would be great to have 50 rooms, an indoor pool, a movie theatre, guest quarters, and a 10 acre yard. Who could argue with this?

But do you have enough money for all those features, and how long will they take?

On the other hand, you could design a one-room log cabin. It would be really cheap and finished quickly.

But you will outgrow the house soon, and wish you had spent some more time and money on it.

So what is the right compromise between usefulness, price and time when designing a house? These are exactly the same issues when specifying software.

Feature Set Control means limiting the number of features that you promise to customers during the requirements analysis. Just writing a great requirements document is not good enough, if the list of features you outline would need 1000 programmers for 10 years.

Feature set control is probably the single most important issue in software engineering. An overly ambitious feature set, or feature creep, has probably sunk more projects than any other factor.

It ruins quality efforts, because you can't do anything well if you are trying to do too much.
It makes people quit, because their hard work is never enough.
It makes estimating impossible, because the projects are too complex to estimate and/or the feature set is a moving target.

Examples...

VMS system management console that I worked on. (It was a GUI on top of a command line interface.) There had been an earlier version of the software. The initial feature list for this version was huge, since they wanted all of the old features plus lots of new ones. The project collapsed under its own complexity. Many pieces of the software did not work correctly. Every deadline was missed. Last I knew, they were still working on it years later.
Linux 2.4 kernel. Classic case of feature creep. Linus wanted short release cycles, but keeps adding more and more features. The release date keeps slipping. Could impact quality, because he is compressing the beta test time.

Goal of feature set control -- Define a modest, manageable set of features initially, and hold this set fairly stable throughout the project.

Why is this so hard?

Marketing / sales pressure to have everything.
Users don't know what they want in the beginning.
Some things are not clear until you see them; you don't know you need a feature until you see the system working.

How to do it...

1) Early reduction of feature list

Write a minimal spec, and let developers find the easy way. A printed report is a good example. (But make sure the developers actually look for the easy way.)
Scrub the spec. Get everyone involved in this.
Plan for multiple versions. (Elaborate why this is good.)

2) Control feature creep during project.

Use a triage teams with someone from each affected group.
Effect of even considering a change (on sizable project) is at least 1 day. Explain why. Make sure everyone connected with the project knows this.
Effect of making a small change is 2-10 days. Why? Make sure everyone knows this.
But, don't try to eliminate change. This is overly rigid and does not reflect business and technical realities. But be aware of the price of change.

3) Late changes and cuts

Changes at the end of a project are VERY expensive. There is no simple fix. Give example of 10-second late change requested of IBM GBP project; caused a 1+ day slip.
This is a good time to say NO to everything, except for major bug repair.
Cutting and deferring features at the end is a good way to meet a schedule.

Technical Writing

Background of the Plain English movement... A big push in many areas to make documents readable. Covers financial statements (a la SEC) but also insurance policies, tax return instructions, etc.

Who is Warren Buffet? Amazing that he cannot understand many of the financial statements that he tries to read!

Student comments on the SEC Plain English manual?

My top 5 tips for good writing....

- Decide who your audience is, state it, and stick with it.

You cannot write to all types of readers at once. You must make an informed decision about who you are writing to. (This is not always easy.)

Examples: company annual report (audience?), user manual for Microsoft Excel (audience?), Unix system administration guide (audience?)

Example of being too technical -- Warren Buffet's example of an annual report that he could not read.

Example of being too elementary -- Explaining how to insert a diskette in a book about Java programming.

TIP -- Technical writing usually assumes too high a level of expertise. This is common for system admin guides.

TIP -- If you cannot choose an audience, you probably need to write more than one document for different audiences.

- Use a clear organization, so the reader can find topics.

Unless the document is very short, start with a TOC.

Use multiple levels of headings, that follow the TOC.

Put white space before and after headings and sections.

Use big enough type (12 points), space between lines, and margins.

- Once you have an organization, stick with it as you write.

Write about the topic that the heading says you are writing about, not something else.

If you must write about something else, re-examine your outline. It could be that you have not included the necessary background for the current topic.

- Go from general to specific.

Example -- In a functional specification, first state the purpose of the program or what problem it solves. Then describe its detailed features.

Example -- In a status report to your boss, first state the summary (the project is on time, the project is far behind schedule), then explain the details.

Apply this at the macro and low level. In the first chapter of a book, give an overview of the topic. In the first paragraph of each chapter, give an overview of the chapter. In the first sentence of each paragraph, state the main idea of the paragraph, then expand on it.

- Use plain English.

Only use technical jargon when it is really necessary.

Regular words and simple sentences make you a good writer. Fancy words and long sentences do not make you a better writer.

David Halberstam and John Steinbeck exemplify this. They write about complex, interesting topics, by using simple language.

Can you decode this business jargon? value proposition (why are we doing this), collaborative development (work together), transformation management (change things), knowledge transfer (tell someone something), enabling technologies (new computers or software).