How To Put Dick Inside Underwear

Object Oriented Analysis Requirements Analysis (Part 2)

TECHNICAL REQUIREMENTS DETERMINATION

- conversations, interviews, meetings with the client . We may find several problems:

• the differences between users, get diverse views . The idea is completion of all interviews possible to cover all these points and look better.
• users not usually have experience or knowledge system.
• get an idea of \u200b\u200bthe system, defining only the technique is complicated. You need to use alternative techniques for more information. INTERVIEW PHASES

1. Preparation. Determine the questions going to be (get a study on the problem domain), select a subset of people to get as many details as possible, determine the purpose and content the same and planned. Making
   
2. . It has 3 parties. In the opening made clear to the user what the purpose of the interview and clarify concepts or specific notation to be used during the meeting. In the development , up to 2 hours, we have to maintain control and allow the user to explain, we must avoid monologues by the interviewers. Al final to do a recap of the information given by the user.
3. Analysis of the interviews, we extract the information gathered by my

- Get requirements from Information System (synonymous with computer system) developed. We can use this technique as a complement to the previous one since it can give much more useful information (in some cases users will not work with specific data). That if the problem lies in complex systems and systems that have never existed.

- Get the requirements from the same information system. analysts need to know what already exists in the company where we will put the new system. The problem with this technique is that it is expensive as it is added to this phase an analysis of what is already there and that takes time and more staff to do so.

- Construction of a prototype . We define a prototype with the general characteristics of the system and we meet the requirements based on the versions. This technique is very expensive.

- Use Cases. It identifies the functional and nonfunctional requirements and relate to them. We ask ourselves what are the functions of the system for each actor (person connected to the system.)


WHAT IS IN THE ANALYSIS OF REQUIREMENTS?

1. Understanding the problem through understanding (forgive the redundancy) of the software within the context and the assessment and synthesis of the problem itself (definition of flows, structure and content of information understanding of roles and behavior) modeling system
3. system specification using a formal representation comprovación that what the analyst has collected is what the customer really needs. Issue

- One of the first conflicts with what we have is in deciding which people can give us the information we need to raise the client's needs. We found that a high percentage of people who asked not really give us.
- Probably for the same function we find different information from different people, so which becomes inconsistent information.
- We can find problems in time to integrate our new system because of the operation and performance of other system elements. For example, I can meet with errors when I decide to connect to other software for data.
- The perception of the objectives may change over time.
- As the problem size grows, the analysis becomes more complex.
- The client does not usually value the analysis stage.

modeling methods
Each method of analysis is a notation and an own point of view, but always has to be 3 rules:

1. Partition . a complex system can only be understood if divided into smaller parts that relate to each other, this allows us to see the problem into smaller parts and then, their relationship, come to have an overview of it. Abstraction
2. . should allow us to see the system in general, regardless of how we generate inputs and outputs of the system. Projection
3. . to define the problem taking into account the different points of view.

requirements specification is the result of the analysis. This is a document which serves as a contract between the developer and the customer base and work for the designer.

- Explains what the system, not the how.
- a document should be understandable to anyone. It requires the explanation of the technicalities in the case of any.
- explain the concepts should be clear.
- The information must be complete, must collect all the requirements and in turn, these must be verified by the customer.
- There should be no conflicting requirements.
- Must be a document easily editable.
- must have an index.
- Duty to be usable during the design and implementation, and maintenance system.

- A standard of this document is to ANSI / IEEE.

- then the document should be reviewed and validated at two levels: macroscopic (full specification, consistent and accurate) and detailed (state specific topics).