Chapter 2 Investigating requirements

Analysis activities Gather detailed information Define requirements Prioritize requirements Develop user-interface dialogs Evaluate requirements with users Different kind of requirements System requirements Are all the activities the new system must perform or support and the constraints that the new system must meet. Generally, analysts divide system requirements into two categories: functional and non-functional requirements. Functional requirements Are the activities that the system must perform (i.e., the business uses to which the system will be applied). Stakeholders These are your primary source of information for system requirements. Stakeholders are all the people who have an interest in the successful implementation of the system. Depending on the nature and scope of the system, this can be a small or a large, diverse group. Information Gathering Techniques Techniques for gathering detailed requirements information include:

Interviewing users and other stakeholders Distributing and collecting questionnaires Reviewing inputs, outputs, and documentation Observing and documenting business procedures Researching vendor solutions Collecting active user comments and suggestions Research Vendor Solutions Many of the problems and opportunities that companies want to address with new information systems have already been solved by other companies. In addition, consulting firms often have experience with the same problems, and software firms may have already packaged solutions for a particular business need. Taking advantage of existing knowledge or solutions can avoid costly mistakes and save time and money. Activity Diagrams An activity diagram describes the various user (or system) activities, the person who does each activity, and the sequential flow of these activities. (See figure 2-14 on page 58)

Chapter 3 Use Cases Functional Requirements A functional requirement describes what a software system should do An example of a functional requirement would be that a system must send an email whenever a certain condition is met (e.g. an order is placed, a customer signs up, etc). Non-functional requirements Non-functional requirements place constraints on how the system will do so. A related non-functional requirement for the system may be that emails should be sent with a latency of no greater than 12 hours from such an activity. To sum it up The functional requirement is describing the behaviour of the system as it relates to the system's functionality. The non-functional requirement elaborates a performance characteristic of the system. Event Decomposition The event decomposition technique focuses on identifying the events to which a system must respond and then determining how a system must respond (i.e., the systems use cases). When defining the requirements for a system, it is useful to begin by asking, What business events occur that will require the system to respond? By asking about the events that affect the system, you direct your attention to the external environment and look at the system as a black box. This initial perspective helps keep your focus on a

high-level view of the system (looking at the scope) rather than on the inner workings of the system. It also focuses your attention on the systems interfaces with outside people and other systems.

CRUD Analysis CRUD is an acronym for Create, Read or Report, Update, and Delete, and it is often introduced with respect to database management. The analyst starts by looking at the types of data stored by the system, which are modelled as data entities or domain classes. To validate and refine use cases, the analyst looks at each type of data and verifies that use cases have been identified that create the data, read or report on the data, update the data, and delete (or archive) the data.

Types of Events There are three types of events to consider when using the event decomposition technique to identify use cases: external events, temporal events, and state events (also called internal events). The analyst begins by trying to identify and list as many of these events as possible, refining the list while talking with system users.
-

External Events (pg 72) An external event is an event that occurs outside the systemusually initiated by an external agent or actor. Temporal Events (pg 73) This is an event that occurs as a result of reaching a point in time. Many information systems produce outputs at defined intervals, such as payroll systems that produce a pay check every two weeks (or each month). Sometimes, the outputs are reports that management wants to receive regularly, such as performance reports or exception reports. These events are different from external events in that the system should automatically produce the required output without being told to do so. State Event This is an event that occurs when something happens inside the system that triggers the need for processing. State events are also called internal events. For example, if the sale of a product results in an adjustment to an inventory record and the inventory in stock drops below a reorder point, it is necessary to reorder.

Chapter 4 Domain Modelling Techniques for data modelling Data modelling is the formalization and documentation of existing processes and events that occur during application software design and development. Data modelling techniques and tools capture and translate complex system designs into easily understood representations of the data flows and processes, creating a blueprint for construction and/or re-engineering. Data modellers often use multiple models to view the same data and ensure that all processes, entities, relationships and data flows have been identified. There are several different approaches to data modelling, including:
-

Conceptual Data Modelling Identifies the highest-level relationships between different entities. Enterprise Data Modelling Similar to conceptual data modelling, but addresses the unique requirements of a specific business. Logical Data Modelling Illustrates the specific entities, attributes and relationships involved in a business function. Serves as the basis for the creation of the physical data model. Physical Data Modelling Represents an application and database-specific implementation of a logical data model.

Attributes / Things Domain classes or data entities are what end users deal with when they do their workfor example, products, sales, shippers, shipments, and customers. These are often referred to as things in the context of a systems problem domain. There are many techniques for identifying the important things in the problem domain. Two of them are introduced in this chapter: the brainstorming technique and the noun technique.
-

Brainstorming Technique As with use cases, an analyst should ask the users to discuss the types of things they work with routinely. The analyst can ask about several types of things to help identify them. Many things are tangible and therefore more easily identified, but others are intangible. Different types of things are important to different users, so it is important to involve all types of users to help identify problem domain things.

The Noun Technique Recall that a noun is a person, place, or thing. Therefore, identifying nouns might help you identify what needs to be stored by the system. Begin by listing all the nouns that users mention when talking about the system. Nouns used to describe events, use cases, and the actors are potential things. Next, add to the list any additional nouns that appear in information about the existing system or that come up in discussions with stakeholders about the problem domain of the system. The list of nouns will become quite long, so the list will need to be refined. How the noun technique differs from the brainstorming technique is that the analyst lists all nouns without thinking too much about them and without talking much to users. Only later will the list be refined based on consultation with stakeholders and users.

Attributes A customer has a name, a phone number, a credit limit, and so on. Each of these details is an attribute. The analyst needs to identify the attributes of each thing that the system needs to store. One attribute may be used to identify a specific thing, such as a Social Security number for an employee or an order number for a purchase. The attribute that uniquely identifies the thing is called an identifier or key. Sometimes, the identifier is already established (a Social Security number, vehicle ID number, or product ID number). Sometimes, the system needs to assign a specific identifier (an invoice number or transaction number). Domain Class Diagram vs. Entity relationship model Class diagram/model represents both structural and behaviour features of a system (attribute and operations). Class models act as a mould for the object instance. In class model, classes related to each other in association relationship, part-whole relationship and generalization relationship. Class models are more likely to map into real-world objects. The entity model more likely to map into tables in database (repetitive records)

Chapter 5 Extending the requirements models Events and Use Cases (pg 121) A list of use cases and use case diagrams provides an overview of all the use cases for a system. Detailed information about each use case is described with a use case description.

Use Case Diagrams

Automation Boundary The boundary between the computerized portion of the application and the users who operate the application but are part of the total system

<<includes>> Relationships Frequently during the development of a use case diagram, it becomes apparent that one use case might use the services of another use case. (Page 82 for explanation) System Sequence Diagram

Activity Diagram

Chapter 8 Approaches to software development SDLC What are the phases? Preliminary Analysis: The objective of phase 1 is to conduct a preliminary analysis, propose alternative solutions, describe costs and benefits and submit a preliminary plan with recommendations.
-

Conduct the preliminary analysis: in this step, you need to find out the organization's objectives and the nature and scope of the problem under study. Even if a problem refers only to a small segment of the organization itself then you need to find out what the objectives of the organization itself are. Then you need to see how the problem being studied fits in with them. Propose alternative solutions: In digging into the organization's objectives and specific problems, you may have already covered some solutions. Alternate proposals may come from interviewing employees, clients , suppliers, and/or consultants. You can also study what competitors are doing. With this data, you will have three choices: leave the system as is, improve it, or develop a new system. Describe the costs and benefits. Systems analysis, requirements definition: Defines project goals into defined functions and operation of the intended application. Analyses end-user information needs. Systems design: Describes desired features and operations in detail, including screen layouts, business rules, process diagrams, pseudocode and other documentation. Development: The real code is written here. Integration and testing: Brings all the pieces together into a special testing environment, then checks for errors, bugs and interoperability. Acceptance, installation, deployment: The final stage of initial development, where the software is put into production and runs actual business. Maintenance: What happens during the rest of the software's life: changes, correction, additions, moves to a different computing platform etc. This is often the longest of the stages.

Difference between adaptive and predictive approaches to design

Waterfall Methodology Predictive Approach Agile Adaptive Approach Methodologies / models / tools / techniques

Methodologies A system development methodology provides guidelines for every facet of the systems development life cycle. For example, within a methodology, certain models, such as diagrams, are used to describe and specify the requirements. Related to these models are the techniques for how the project team will do its work. Models Anytime people need to record or communicate information, it is useful to create a model. A model is a representation of an important aspect of the real world. Sometimes, the term abstraction is used because we abstract (separate out) an aspect that is of particular importance to us. Tools In the context of system development, a tool is software support that helps create models or other components required in the project. Tools might be simple drawing programs for creating diagrams. They might also include an application that stores information about the project, such as data definitions, use case descriptions, and other artefacts. Techniques In system development, a technique is a collection of guidelines that helps an analyst complete an activity or task. It often includes step-by-step instructions for creating a model, or it might include more general advice on collecting information from system users. Examples include data-modelling techniques, software-testing techniques, user-interviewing techniques, and relational database design techniques. What is the agile philosophy? The Manifesto for Agile Software Development identifies four basic values, which represent the core philosophy of Agile development: Value responding to change over following a plan Value individuals and interactions over processes and tools Value working software over comprehensive documentation Value customer collaboration over contract negotiation

1. 2. 3. 4.

Chapter 10 OO Design: principles Component diagrams (do not need to draw) The component diagram identifies the logical, reusable, and transportable system components that define the system architecture. The essential element of a component diagram is the component element with its interfaces. A component is an executable module or program, and it consists of all the classes that are compiled into a single entity. It has well-defined interfaces, or public methods, that can be accessed by other programs or external devices.

3 layer architecture

This involves one more layer called the business logic tier, service tier or middle tier (layer). In the client-server (2 layer) solution the client was handling the business logic and that makes the client thick. A thick client means that it requires heavy traffic with the server, thus making it difficult to use over slower network connections like Internet and Wireless (LTE, 3G, or Wi-Fi). By introducing the middle layer, the client is only handling presentation logic. This means that only little communication is needed between the client and the middle tier making the client thin or thinner. As more users access the system a three-tier solution is more scalable than the other solutions because you can add as many middle tiers (running on each own server) as needed to ensure good performance Deployment diagrams Deployment diagrams model the physical deployment of artefacts on nodes. To describe a web site, for example, a deployment diagram would show what hardware components ("nodes") exist (e.g., a web server, an application server, and a database server), what software components ("artefacts") run on each node (e.g., web application, database), and how the different pieces are connected. See attached example, even though you can hardly see the words:

Detailed Design What is detailed design? When most people talk about detailed design, they are referring to a process known as top-down design. In short, when you think about the problem you are trying to solve, you start at the highest level and then work yourself into the details. This approach works very well when you have an overall structure you want your application to live within. At the macro level you are considering how many machines will be needed to host your application, which existing services you will need to use, etc. As you dive deeper, you are looking at use cases (or user stories if you prefer that terminology), and error handling (use cases have both normal and error condition paths to worry about). As you go even further into the details, you are looking at your algorithm, state transitions, logical sequence, and how internal parts of the code work together. CRC (class-responsibility-collaboration) Cards These help provide an overall understanding of the internal steps required for the system to support the use case. CRC cards provide a simple method for identifying all the objects involved in a particular use case and their responsibilities. The results of a CRC activity will be sets of cards that can be used to help develop a sequence diagram; if a use case is simple enough, the cards can be used to program the use case.

Development of the design class diagram (include methods, attributes and data types)

Chapter 11 OO design: Use case realisation There will be a big sequence diagram in the exam based on the case study Know how to draft a first cut sequence diagram Know how to complete the design class diagram Dont worry about: multilayer design, package diagram, communication diagram Study the questions at the end of chapter 11

Chapter 14 Current trends What are the phases and disciplines of the unified process? A phase in the UP can be thought of as a goal or major emphasis for a particular portion of the project. The four phases of the UP life cycle are: inception, elaboration, construction, and transition, as shown in Figure

What is the agile philosophy? The Manifesto for Agile Software Development identifies four basic values, which represent the core philosophy of Agile development: Value responding to change over following a plan Value individuals and interactions over processes and tools Value working software over comprehensive documentation Value customer collaboration over contract negotiation What are the modelling principles and practises that agile prescribe? The relationship between agile values, principles, and practices

1. 2. 3. 4.

Agile Principles
Rapid Feedback Assume simplicity Make incremental change Embracing change Quality work

Agile Practises Continuous Integration Simple design Pair programming Extreme programming, Pragmatic programming

Extreme Programming be able to discuss core values and practices

-

Practices Planning Testing Pair programming Simple designs Refactoring the code Owning the code collectively Continuous integration On-site customer System metaphor Small releases Forty-hour week Coding standards Core values
Communication Simplicity Feedback Courage

Scrum how does a scrum project work? Those of you who are familiar with rugby are aware that when a team gets possession of the ball, it attempts to go the entire distance in one continuous play from point of possession to the score. The team works together, passing the ball back and forth; even when tackled; it can maintain possession and keep the ball in play. Scrum Philosophy The Scrum philosophy is based on the Agile Development principles described earlier. Scrum is responsive to a highly changing, dynamic environment in which users might not know exactly what is needed and might also change priorities frequently. In this type of environment, changes are so numerous that projects can bog down and never reach completion. Scrum excels in this type of situation. Scrum focuses primarily on the team level. It is a type of social engineering that emphasizes individuals more than processes and describes how teams of developers can work together to build software in a series of short mini-projects.