Lecture: Why do Analysis and Design?
Published Thursday, March 16, 2006 by Mathieu | E-mail this post
This kind of stuff will be useful in a real job. For IT professionals it's used a lot.
It's also in prep for 3302.
Definitions.
Systems analysis goes back to before we had computers.
In those days there was a clear distinction.
Description of the problem (WHAT) Role of the analyst. Essential model
(HOW) Description of the solution. Which platform / language? This is design. This is looking at thinking of alternate ways of solving problems and choosing the best one. A description of the Solution.
Implementation model.
Often, the role of analyst and designer are merged (jobs advertised as such) But there are organisations where this is separate.
In computing, when they decided that there was need of methodically building software, in the 80's and 90's, they built a wall between the analysis and design. There was a clear distinction.
There was also an increasing emphasis on requirements analysis. What is an acceptable solution.
Some commentators say that the analysis is the important bit, with all different levels of design.
But people moved away from it. It was difficult to do things seamlessly.
What is the problem? What is an acceptable solution?
Systems analysis is thinking about what is really going on. What is the nature and extent of the problem?
Defining a problem
Gathering the requirements. Constraints on acceptable solution.
You get a sense of satisfaction when your program works :-) But after a while you get used to it and you want to look for more difficult problems.
Why do analysis and design.
The alternatives aren't very pretty...
We add formality. People can get the same answer by getting lucky.
To get the requirements right!
People do studies on the sources of errors
Types of analysis and design. There are many!
If one of them worked, we wouldn't need all the others (hangover cures)
Top Down
"Big Picture" limit errors of omission
Structured analysis
SADT
Object-Oriented Analysis and Design.
Entity Analysis
-information
-that can carry out an action
-modelled by an object.
People claim that is the best way of doing things.
Object Modelling Technique (OMT)
UML - How to communicate design, but not what should go in your diagrams.
Data-Driven Analysis and Design
The computer is a means to an end. The important bit is the information. The computer is a way of managing and accessing that information.
Requirements Engineering:
Challenge facing system and software engineers.
How do I satisfy the user demands? If I don't, they're not going to pay for this!
(See the list on the slides)
Requirements Elicitation.
What what what?
They're trying to describe something.
It might seem simple but in fact it's hard!
Problems of scope. Who is going to interact with the system? What is the boundary.
What other systems>
Use these slides as a reference for things to do while doing analysis and design.
Problems of Understanding
"See what you can do to help us"
"Try to improve the project"
People might had no idea what needs to be done. And have trouble communicating it. They might omit info that believed to be obvious.
Problems of Volatility
Requirements change over time
Change is inevitable in most systems.
There are changes in scale, organisation (new divisions / products)
Changes in the law, in international standards (eg. MPEG)
Customers get new ideas as they become away for the possibilities.
Overcoming Requirements Elicitation problems.
There might be parts of an organisation that the person doesn't know anything about.
You need to know the technical domain in which the software will be placed.
You can use interview, focus groups, team meetings, talking with stakeholders.
You want to keep this information not just in the head of a few gurus, but in various documents.
It's also in prep for 3302.
Definitions.
Systems analysis goes back to before we had computers.
In those days there was a clear distinction.
Description of the problem (WHAT) Role of the analyst. Essential model
(HOW) Description of the solution. Which platform / language? This is design. This is looking at thinking of alternate ways of solving problems and choosing the best one. A description of the Solution.
Implementation model.
Often, the role of analyst and designer are merged (jobs advertised as such) But there are organisations where this is separate.
In computing, when they decided that there was need of methodically building software, in the 80's and 90's, they built a wall between the analysis and design. There was a clear distinction.
There was also an increasing emphasis on requirements analysis. What is an acceptable solution.
Some commentators say that the analysis is the important bit, with all different levels of design.
But people moved away from it. It was difficult to do things seamlessly.
What is the problem? What is an acceptable solution?
Systems analysis is thinking about what is really going on. What is the nature and extent of the problem?
Defining a problem
Gathering the requirements. Constraints on acceptable solution.
You get a sense of satisfaction when your program works :-) But after a while you get used to it and you want to look for more difficult problems.
Why do analysis and design.
The alternatives aren't very pretty...
We add formality. People can get the same answer by getting lucky.
To get the requirements right!
People do studies on the sources of errors
Types of analysis and design. There are many!
If one of them worked, we wouldn't need all the others (hangover cures)
Top Down
"Big Picture" limit errors of omission
Structured analysis
SADT
Object-Oriented Analysis and Design.
Entity Analysis
-information
-that can carry out an action
-modelled by an object.
People claim that is the best way of doing things.
Object Modelling Technique (OMT)
UML - How to communicate design, but not what should go in your diagrams.
Data-Driven Analysis and Design
The computer is a means to an end. The important bit is the information. The computer is a way of managing and accessing that information.
Requirements Engineering:
Challenge facing system and software engineers.
How do I satisfy the user demands? If I don't, they're not going to pay for this!
(See the list on the slides)
Requirements Elicitation.
What what what?
They're trying to describe something.
It might seem simple but in fact it's hard!
Problems of scope. Who is going to interact with the system? What is the boundary.
What other systems>
Use these slides as a reference for things to do while doing analysis and design.
Problems of Understanding
"See what you can do to help us"
"Try to improve the project"
People might had no idea what needs to be done. And have trouble communicating it. They might omit info that believed to be obvious.
Problems of Volatility
Requirements change over time
Change is inevitable in most systems.
There are changes in scale, organisation (new divisions / products)
Changes in the law, in international standards (eg. MPEG)
Customers get new ideas as they become away for the possibilities.
Overcoming Requirements Elicitation problems.
There might be parts of an organisation that the person doesn't know anything about.
You need to know the technical domain in which the software will be placed.
You can use interview, focus groups, team meetings, talking with stakeholders.
You want to keep this information not just in the head of a few gurus, but in various documents.
0 Responses to “Lecture: Why do Analysis and Design?”
Leave a Reply