software engineering principles

Scenarios

A structured form of user story Scenarios should include A description of the starting situation; A description of the normal flow of events; A description of what can go wrong; Information about other concurrent activities; A description of the state when the scenario finishes. Scenarios may be written as text, supplemented by diagrams, screen shots, use cases, etc. Scenarios and user stories are real-life examples of how a system can be used. Stories and scenarios are a description of how a system may be used for a particular task. Because they are based on a practical situation, stakeholders can relate to them and can comment on their situation with respect to the story. A scenario is a scene that illustrates some interaction with a proposed system. A scenario is a tool used during requirements analysis to describe a specific use of a proposed system. Scenarios capture the system, as viewed from the outside, e.g., by a user, using specific examples.

UML diagram types

Activity diagrams, which show the activities involved in a process or in data processing . Use case diagrams, which show the interactions between a system and its environment. Sequence diagrams, which show interactions between actors and the system and between system components. Class diagrams, which show the object classes in the system and the associations between these classes. State diagrams, which show how the system reacts to internal and external events.

Use Cases and Actors

Actor is a role NOT an individual Actor must be a beneficiary of the use case In naming actors, choose names that describe the role, not generic names like "user" and "client".

Structured Natural Language specifications

An approach to writing requirements where the freedom of the requirements writer is limited and requirements are written in a standard way. This works well for some types of requirements e.g. requirements for embedded control system but is sometimes too rigid for writing business system requirements. Definition of the function or entity. Description of inputs and where they come from. Description of outputs and where they go to. Information about the information needed for the computation and other entities used. Description of the action to be taken. Pre and post conditions (if appropriate). The side effects (if any) of the function.

Motivating people

An important role of a manager is to motivate the people working on a project. Motivation means organizing the work and the working environment to encourage people to work effectively. Motivation is a complex issue but it appears that their are different types of motivation based on: Basic needs (e.g. food, sleep, etc.); Personal needs (e.g. respect, self-esteem);Social needs (e.g. to be accepted as part of a group).

Requirement Analysis: Viewpoint Analysis

Analyze the requirements as seen by each group of stakeholders Example: University Admissions System Applicants University administration Admissions office Financial aid office Special offices (athletes, development) Academic departments Computing staff Operations and maintenance Understanding the requirements may need studies: Market research: focus groups, surveys, competitive analysis. Technical evaluation: experiments, prototypes

Use of graphical models

As a means of facilitating discussion about an existing or proposed system Incomplete and incorrect models are OK as their role is to support discussion. As a way of documenting an existing system Models should be an accurate representation of the system but need not be complete. As a detailed system description that can be used to generate a system implementation Models have to be both correct and complete.

Models for Requirements Analysis and Specification

As you build understanding of the requirements through viewpoint analysis, scenarios, use cases, etc., use models to analyze and specify requirements. The model provides a bridge between the client's understanding and the developers'. The craft of requirements analysis and specification includes selecting the appropriate tool for the particular task.

Risk analysis

Assess probability and seriousness of each risk. Probability may be very low, low, moderate, high or very high. Risk consequences might be catastrophic, serious, tolerable or insignificant.

Planning stages

At the proposal stage, when you are bidding for a contract to develop or provide a software system. During the project startup phase, when you have to plan who will work on the project, how the project will be broken down into increments, how resources will be allocated across your company, etc. Periodically throughout the project, when you modify your plan in the light of experience gained and information from monitoring the progress of the work.

Why are Requirements Important?

Causes of failed software projects Failure to understand the requirements led the developers to build the wrong system.

Requirements validation

Concerned with demonstrating that the requirements define the system that the customer really wants. Requirements error costs are high so validation is very important Fixing a requirements error after delivery may cost up to 100 times the cost of fixing an implementation error.

Risk planning

Consider each risk and develop a strategy to manage that risk. Avoidance strategies The probability that the risk will arise is reduced Minimization strategies The impact of the risk on the project or product will be reduced; Contingency plans If the risk arises, contingency plans are plans to deal with that risk;

People management factors

ConsistencyTeam members should all be treated in a comparable way without favourites or discrimination. Respect Different team members have different skills and these differences should be respected. Inclusion Involve all team members and make sure that people's views are considered. Honesty You should always be honest about what is going well and what is going badly in a project.

The Project Manager

Create and maintain the schedule Track progress against schedule Keep some slack in the schedule (minimize risk) Continually make adjustments: Start activities before previous activity complete Sub-contract activities Renegotiate deliverables Keep senior management informed (visibility). The project manager needs the support of the head of the development team and the confidence of the team members.

Functional requirements

Describe functionality or system services. Depend on the type of software, expected users and the type of system where the software is used. Functional user requirements may be high-level statements of what the system should do. Functional system requirements should describe the system services in detail. Functional requirements describe the functions that the system must perform. Example: Healthcare system: Functional requirements A user shall be able to search the appointments lists for all clinics. The system shall generate each day, for each clinic, a list of patients who are expected to attend appointments that day. Each staff member using the system shall be uniquely identified by his or her 8-digit employee number. Requirements imprecision Problems arise when functional requirements are not precisely stated. Ambiguous requirements may be interpreted in different ways by developers and users. Consider the term 'search' in requirement 1 User intention - search for a patient name across all appointments in all clinics; Developer interpretation - search for a patient name in an individual clinic. User chooses clinic then search.

Challenges

Estimating the difficulty of problems and hence the cost of developing a solution is hard. Productivity is not proportional to the number of people working on a task. Adding people to a late project makes it later because of communication overheads. The unexpected always happens. Always allow contingency in planning

How to minimize risks?

Feasibility study: whether to begin a project or not Separation of requirements ( = what client want) from design (how the developers meet those requirements) Milestones: progress reports or releases Acceptance (client tests the software to see if it meets the requirements) and user testing (done jointly with developers) Handover: ensure the client is empowered to operate and maintain the product

Interviewing

Formal or informal interviews with stakeholders are part of most RE processes. Types of interview Closed interviews based on pre-determined list of questions Open interviews where various issues are explored with stakeholders. Effective interviewing Be open-minded, avoid pre-conceived ideas about the requirements and are willing to listen to stakeholders. Prompt the interviewee to get discussions going using a springboard question, a requirements proposal, or by working together on a prototype system.

Functional and non-functional requirements

Functional requirements Statements of services the system should provide, how the system should react to particular inputs and how the system should behave in particular situations. May state what the system should not do. Non-functional requirements Constraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc. Often apply to the system as a whole rather than individual features or services. Domain requirements Constraints on the system from the domain of operation

Mixed Processes

In practice, many large projects use processes that mix aspects of the three types of software process For example: With spiral development, new components may be developed using any of the three other methods User interfaces have to be tested with users. This forces iterative development, even within an underlying sequential process Used when certain parts of the system may be well understood but other parts require iterative refinement to clarify the specifications. provides support for Risk Handling Each loop of the spiral is called a Phase of the software development process. quadrants: Objectives determination and identify alternativesolutions - Identify and resolve Risks =Develop next version of the Product: -Review and plan for the next Phase:

Guidelines for writing requirements

Invent a standard format and use it for all requirements. Use language in a consistent way. Use shall for mandatory requirements, should for desirable requirements. Use text highlighting to identify key parts of the requirement. Avoid the use of very high level technical words. Include an explan

Agile maintenance

Key problems are: Lack of product documentation Keeping customers involved in the development process Maintaining the continuity of the development team Agile development relies on the development team knowing and understanding what has to be done. For long-lifetime systems, this is a real problem as the original developers will not always work on the system.

Practical problems with agile methods

Legal Issues: The informality of agile development is incompatible with the legal approach to contract definition that is commonly used in large companies. Maintenance: Agile methods are most appropriate for new software development rather than software maintenance.. Scale: Agile methods are designed for small co-located teams yet much software development now involves worldwide distributed teams.

Existing and planned system models

Models of the existing system are used during requirements engineering. They help clarify what the existing system does can be used as a basis for discussing its strengths and weaknesses Then lead to requirements for the new system. Models of the new system are used during requirements engineering to help explain the proposed requirements to other system stakeholders. Engineers use these models to discuss design proposals and to document the system for implementation. In a model-driven engineering process, it is possible to generate a complete or partial system implementation from the system model.

Interviews in practice

Normally a mix of closed and open-ended interviewing. Interviews are good for getting an overall understanding of what stakeholders do and how they might interact with the system. You need to prompt the use to talk about the system by suggesting requirements rather than simply asking them what they want.

Managing people

People are an organisation's most important assets. The tasks of a manager are essentially people-oriented. Unless there is some understanding of people, management will be unsuccessful. Poor people management is an important contributor to project failure.

Agile Approach to Project Management

Planning is divided into high level release forecasting and low level detailed planning Release planning is a best guess, high level view of what can be achieved in a sequence of time-boxes Release plans are continually modified, perhaps daily The system is developed as a series of versions or increments with stakeholders involved in version specification and evaluation Minimal documentation - focus on working code For each time-box, the team plans what it can achieve The team may use Gantt charts or other conventional planning tools

Rapid Software Development

Rapid development and delivery is now often the most important requirement for software systems Businesses operate in a fast -changing requirement and it is practically impossible to produce a set of stable software requirements Software has to evolve quickly to reflect changing business needs. Plan-driven development is essential for some types of system but does not meet these business needs. Agile development methods emerged in the late 1990s whose aim was to radically reduce the delivery time for working software systems

Requirements reviews

Regular reviews should be held while the requirements definition is being formulated. Both client and contractor staff should be involved in reviews. Reviews may be formal (with completed documents) or informal. Good communications between developers, customers and users can resolve problems at an early stage.

These steps may be repeated many times during the development cycle

Requirements User Interface Design System and program design Implementation (coding) Acceptance and release

Natural language specification

Requirements are written as natural language sentences supplemented by diagrams and tables. Used for writing requirements because it is expressive, intuitive and universal. This means that the requirements can be understood by users and customers. Lack of clarity Precision is difficult without making the document difficult to read. Requirements confusion Functional and non-functional requirements tend to be mixed-up. Requirements amalgamation Several different requirements may be expressed together.

Process activities(summary)

Requirements discovery Interacting with stakeholders to discover their requirements. Domain requirements are also discovered at this stage. Requirements classification and organisation Groups related requirements and organises them into coherent clusters. Prioritisation and negotiation Prioritising requirements and resolving requirements conflicts. Requirements specification Requirements are documented and input into the next round of the spiral.

Realism and Verifiability

Requirements must be realistic, i.e., it must be possible to meet them. Wrong: the system must be capable of x (if no known computer system can do x at a reasonable cost). Requirements must be verifiable, i.e., since the requirements are the basis for acceptance testing, it must be possible to test whether a requirement has been met. Wrong: the system must be easy to use (what does easy to use mean??).

Requirements validation techniques

Requirements reviews Systematic manual analysis of the requirements. Prototyping Using an executable model of the system to check requirements. Test-case generation Developing tests for requirements to check testability.

The Risk Management process

Risk identification Identify project, product and business risks; Risk analysis Assess the likelihood and consequences of these risks; Risk planning Draw up plans to avoid or minimize the effects of the risk; Risk monitoring Monitor the risks throughout the project;

Risk management

Risk management is concerned with identifying risks and drawing up plans to minimise their effect on a project. Software risk management is important because of the inherent uncertainties in software development. These uncertainties stem from loosely defined requirements, requirements changes due to changes in customer needs difficulties in estimating the time and resources required for software development differences in individual skills. You have to anticipate risks, understand the impact of these risks on the project, the product and the business, and take steps to avoid these risks.

Modeling Scenarios as Use Cases

Scenarios are useful in discussing a proposed system with a client, but requirements need to be made more precise before a system is fully understood. This is the purpose of requirements modeling A use case provides such a model

Scrum

Scrum is an agile method of PM that focuses on managing iterative development There are three phases in Scrum. The initial phase is an outline planning phase where you establish the general objectives for the project and design the software architecture. This is followed by a series of sprint cycles, where each cycle develops an increment of the system. The project closure phase wraps up the project, completes required documentation such as system help frames and user manuals and assesses the lessons learned from the project. BENEFITS: The product is broken down into a set of manageable and understandable chunks. Unstable requirements do not hold up progress. The whole team have visibility of everything and consequently team communication is improved. Customers see delivery of increments and gain feedback on how the product works. Trust between customers and developers is established and a positive culture is created

The Decision Maker's Viewpoint

Senior member(s) of the client's organization decide whether to begin a major software project. What information do they need? Client: Who is this project for? Scope: What are the boundaries of the project? Benefits: What are the benefits? Can they be quantified? If the software is a product, what are the forecasts of likely sales? Technical: Is the project possible? Is there at least one technical way to carry out the project? Resources: What are the estimates of staff, time, budget, equipment, etc.? Alternatives: What are the options if the project is not done?

Sequence diagrams

Sequence diagrams are part of the UML and are used to model the interactions between the actors and the objects within a system. A sequence diagram shows the sequence of interactions that take place during a particular use case or use case instance. The objects and actors involved are listed along the top of the diagram, with a dotted line drawn vertically from these. Interactions between objects are indicated by annotated arrows.

Requirements elicitation

Software engineers work with a range of system stakeholders to find out about the application domain, the services that the system should provide, the required system performance, hardware constraints, other systems, etc. Stages include: Requirements discovery, Requirements classification and organization, Requirements prioritization and negotiation, Requirements specification.

Requirements elicitation and analysis

Sometimes called requirements elicitation or requirements discovery. Involves technical staff working with customers to find out about the application domain, the services that the system should provide and the system's operational constraints. May involve end-users, managers, engineers involved in maintenance, domain experts, trade unions, etc. These are called stakeholders.

Software process consists of:

Specification-what the system should do and its development constraints Development- production of the software system Validation- validating the development against customer requirements Evolution- making changes to the software in response to changing demands

Problems of requirements elicitation

Stakeholders don't know what they really want. Stakeholders express requirements in their own terms. Different stakeholders may have conflicting requirements. Organisational and political factors may influence the system requirements. The requirements change during the analysis process. New stakeholders may emerge and the business environment may change.

System modeling

System modeling is the process of developing abstract models of a system, with each model presenting a different view or perspective of that system. System modeling has now come to mean representing a system using some kind of graphical notation, which is now almost always based on notations in the Unified Modeling Language (UML). System modelling helps the analyst to understand the functionality of the system and models are used to communicate with customers.

Describing a Use Case

The description should include: The name of the use case summarizing its purpose The actor(s) The flow of events Assumptions about entry conditions

Who is the client?

The person for whom the software development team creates the software The person who provides resources and expects some product in return Often a member of the funding organization

Who is the User?

The person who actually uses the software Customer = user in some cases

Who is the customer?

The person who buys the software or selects it for use in their organization

Requirements engineering

The process of establishing the services that a customer requires from a system and the constraints under which it operates and is developed. The system requirements are the descriptions of the system services and constraints that are generated during the requirements engineering process.

The software requirements document

The software requirements document is the official statement of what is required of the system developers. Should include both a definition of user requirements and a specification of the system requirements. It is NOT a design document. As far as possible, it should set of WHAT the system should do rather than HOW it should do it.

Risk classification

There are two dimensions of risk classification The type of risk (technical, organizational, ..) What is affected by the risk Project risks affect schedule or resources; Product risks affect the quality or performance of the software being developed; Business risks affect the organisation developing or procuring the software.

Non-Functional Requirements

These define system properties and constraints e.g. reliability, response time and storage requirements. Requirements that are not directly related to the functions that the system must perform. Product requirements performance, reliability, portability, etc. Organizational requirements delivery, training, standards, etc. External requirements legal, interoperability, etc. Marketing and public relations CLASSIFICATIONS Product requirements Requirements which specify that the delivered product must behave in a particular way e.g. execution speed, reliability, etc. Organisational requirements Requirements which are a consequence of organisational policies and procedures e.g. process standards used, implementation requirements, etc. External requirements Requirements which arise from factors which are external to the system and its development process e.g. interoperability requirements, legislative requirements, etc. IMPLEMENTATION Non-functional requirements may affect the overall architecture of a system rather than the individual components. For example, to ensure that performance requirements are met, you may have to organize the system to minimize communications between components. A single non-functional requirement, such as a security requirement, may generate a number of related functional requirements that define system services that are required. It may also generate requirements that restrict existing requirements. Goals and requirements Non-functional requirements may be very difficult to state precisely and imprecise requirements may be difficult to verify. Goal A general intention of the user such as ease of use. Verifiable non-functional requirement A statement using some measure that can be objectively tested. Goals are helpful to developers as they convey the intentions of the system users. Usability requirements The system should be easy to use by medical staff and should be organized in such a way that user errors are minimized. (Goal) Medical staff shall be able to use all the system functions after four hours of training. After this training, the average number of errors made by experienced users shall not exceed two per hour of system use. (Testable non-functional requirement)

Mobile Apps: Development Environments App development is complex. Most apps are built using development environments such as Android Studio and Apple's Xcode. There are good tutorials and good documentation online. If you are new to Android or iOS development allow plenty of learning time.

These environments are moderately flexible for user interface design. They support a variety of ways to navigate, user interface objects, etc. But they have limitations (e.g., iOS does not have a radio button). To build a good user experience, understand and adopt the style of the development environment. Users will be familiar with the style of interface from other apps. The interface objects are well designed with good technical implementation. The objects are intended to be used on a variety of devices. When new versions of the operating systems are released, the designs will need few modifications.

Requirement Goals

Understand the requirements in appropriate detail Define the requirements in a manner that is clear to the client. This may be a written specification, prototype system, or other form of communication. Define the requirements in a manner that is clear to the people who will design, implement, and maintain the system Ensure that the client and developers understand the requirements and their implications

Use cases

Use-cases are a kind of scenario that are included in the UML. Use cases identify the actors in an interaction and which describe the interaction itself. A set of use cases should describe all possible interactions with the system. High-level graphical model supplemented by more detailed tabular description UML sequence diagrams may be used to add detail to use-cases by showing the sequence of event processing in the system.

Tabular specification

Used to supplement natural language. Particularly useful when you have to define a number of possible alternative courses of action. For example, the insulin pump systems bases its computations on the rate of change of blood sugar level and the tabular specification explains how to calculate the insulin requirement for different scenarios.

Requirements checking

Validity. Does the system provide the functions which best support the customer's needs? Consistency. Are there any requirements conflicts? Completeness. Are all functions required by the customer included? Realism. Can the requirements be implemented given available budget and technology Verifiability. Can the requirements be checked?

Review checks

Verifiability Is the requirement realistically testable? Comprehensibility Is the requirement properly understood? Traceability Is the origin of the requirement clearly stated? Adaptability Can the requirement be changed without a large impact on other requirements?

Key Points

What are important differences between software project management and other types of project management? The product (software) is intangible. There are no standard software processes Large software projects are often one-off projects. List 4 fundamental project management activities: Project planning, Reporting, Risk management, People management, Proposal writing What are three related categories of risk? Project risks, Product risks, Business risks Suggest 4 risks that may threaten the success of a software project? Staff turnover, management change, hardware unavailability, requirements change, specification delays, size underestimate, CASE tool underperformance, technology change, product competition.. What is involved in risk monitoring? Regularly assessing the project risks to decide whether or not that the risk is becoming more or less probable and whether the effects of the risk have changed. What are the four critical factors in people management? Consistency, Respect, Inclusion, Honesty What are the principal activities in the project scheduling process? Identify activities, Identify activity dependencies, Estimate resources for activities, Allocate people to activities, Create project charts What are the most important differences between agile planning and plan-based development? In plan-based development, a plan for the whole project is drawn up before the project starts and this plan is modified as more information becomes available during the project. In agile planning, planning is iterative and only the next iteration of the software is planned, often in detail. In plan-based development, the schedule is usually extended if problems occur; in agile planning, the system being developed is cut down so that the For what types of system are agile approaches to development particularly likely to be successful? Small and medium-sized software product development. Custom software development in an organization where there is a clear commitment from customers to become involved in the development process. List the 5 principles of agile methods: Customer involvement, Incremental delivery, People not process, Embrace change, Maintain simplicity.

'Help System' Design Help system design is difficult Must prototype with mixed users Must have many routes to same information Categories of help: => Overview and general information => Specific or context information => Tutorials (general) => Cook books and wizards => Emergency ("I am in trouble ...") Help systems need experienced designers. Schedule plenty of time for development and user testing.

Main Stakeholders

- Clients - Customers - Users

Feasibility Study

A feasibility study is a study made before committing to a project. The results of the feasibility study should be a report that recommends whether or not it is worth carrying on with the requirements and development process. In production projects, the feasibility study often leads to a budget request. A feasibility study may be in the form of a proposal.

Feasibility Study: Technical

A feasibility study needs to demonstrate that the proposed system is technically feasible. This requires: an outline of the requirements a possible system design (e.g., database, distributed, etc.) possible choices of software to be acquired or developed estimates of numbers of users, data, transactions, etc. These rough numbers are part of the provisional plan that is used to estimate the staffing, timetable, equipment needs, etc. The technical approach actually followed may be very different.

feasibility

A feasibility study precedes the decision to begin a project

Feasibility Report

A feasibility study should have a written report. It should be a well written, well presented document. For a general audience: client, financial management, technical management, etc. Short enough that everybody reads it. Long enough that no important topics are skipped. Details can be included in supporting documents. A report that is not read and understood is useless.

Feasibility Study: Alternatives and Risks

A feasibility study should identify risks and alternatives.Risks What can go wrong? How will progress be monitored and problems identified (visibility)? What are the fall back options? Alternatives Continue with current system, enhance it, or create new one? Develop in-house, or contract out? (How will a contract be managed?) Phases of delivery and possible points for revising plan.

Activity Graph

A group of scheduling techniques that emphasizes dependencies

Models

A model is a simplification of reality We build models so that we can better understand the system we are developing We build models of complex system because we can't comprehend such a system in its entirety Models can be informal or formal. The more complex the project the more valuable a formal model becomes.

Sprint

A sprint is a set period of time during which a team completes part of a software project Each sprint will go through most of all process steps A typical sprint might have a team of 6-8 people working 2-4 weeks.

Modeling Tools: Transition Diagrams

A system is modeled as a set of states, SiA transition is a change from one state to another. The occurrence of a condition, Ci, causes the transition from one state to another. Transition function: F(Si, Cj) = Sk

Spiral (made popular by MS with OS)

A variant of iterative refinement in which new and updated components are added to the developing system as they are completed

Accessibility Requirements Accessibility Software designers must be prepared to users with disabilities (poor eyesight, lack of hearing, poor manual dexterity) or limited knowledge of English Requirements about accessibility are most likely to arise in the user interface You may have a legal requirement to support people with disabilities

Activity

An activity is a general term of any part of a project that takes place over time (also known as task) Each step in software development can be broken into several activities

An actor is a user of a system in a particular role An actor can be human or an external system

An actor is a user of a system in a particular role An actor can be human or an external system A use case is a task that an actor needs to perform with the help of the system

Velocity

An estimate of how much product backlog effort that a team can cover in a single sprint. Understanding a team's velocity helps them estimate what can be covered in a sprint and provides a basis for measuring improving performance.

System perspectives

An external perspective, where you model the context or environment of the system. An interaction perspective, where you model the interactions between a system and its environment, or between the components of a system. A structural perspective, where you model the organization of a system or the structure of the data that is processed by the system. A behavioral perspective, where you model the dynamic behavior of the system and how it responds to events.

Data - Flow Models

An informal modeling technique to show the flow of data through a system. (usually used for data processing systems)

Flow Chart Models

An informal modeling technique to show the logic of part of a system and paths that data takes through a system.

Risk monitoring

Assess each identified risks regularly to decide whether or not it is becoming less or more probable. Also assess whether the effects of the risk have changed. Each key risk should be discussed at management progress meetings.

Describing a Scenario

At the very least, the description should include: A statement of the purpose of the scenario The individual user or transaction that is being followed through the scenario Assumptions about equipment or software The steps of the scenario

Requirements Specification

Client interviews are the heart of the requirements analysis. Clients may have only a vague concept of requirements. Allow plenty of time Prepare before you meet with the client Keep full notes If you do not understand, delve further, again and again Repeat what you hear How will you collect requirements for your project? The process of writing down the user and system requirements in a requirements document. User requirements have to be understandable by end- users and customers who do not have a technical background. System requirements are more detailed requirements and may include more technical information. The requirements may be part of a contract for the system development It is therefore important that these are as complete as possible.

Professional Responsibility

Competence: Software that does not work effectively can destroy an organization. Confidentiality: Software developers and systems administrators may have access to highly confidential information (e.g., trade secrets, personal data). Legal environment: Software exists in a complex legal environment (e.g., intellectual property, obscenity). Acceptable use and misuse: Computer abuse can paralyze an organization (e.g., the Internet worm).

Waterfall model / Sequential Development

Complete each process step ONCE before beginning the next The waterfall model is a heavyweight process with full documentation of each process step. Advantages: Process visibility Separation of tasks Quality control at each step Cost monitoring at each step Disadvantages: In practice, each stage in the process reveals new understanding of the previous stages, which often requires the earlier stages to be revised. The Waterfall Model may not be flexible enough for some projects. A pure sequential model is sometimes impossible examples: A feasibility study cannot create a proposed budget and schedule without a preliminary study of the requirements and a tentative design. Detailed design and implementation reveal gaps in the requirements specification. Requirements and/or technology may change during the development. The plan must allow for some form of iteration. Sequential processes work best when the requirements are well understood and the design is straightforward Conversions of manual data processing systems where the requirements were well understood and few changes were made during the development (e.g., electricity billing) New models of a product where the functionality is closely derived from an earlier product (e.g. automatic braking system for a car) Portions of a large system where some components have clearly defined requirements and are clearly separated from the rest of the system

Computer Systems & Networks Examples Instantaneous response time is essential for mouse tracking Response time for transactions may determine the action taken, e.g., approve credit card if no reply within 5 seconds Response time requirements 0.1 sec - the user feels that the system is reacting instantaneously 1 sec - the user will notice the delay, but his/her flow of thoughts stays uninterrupted 10 sec - the limit for keeping the user's attention focused on the dialogue As computer systems improve, users have got more demanding. A response time that is good enough today, may not be good enough five years from now

Computer Systems and Networks The performance, reliability and predictability of computer systems and networks are crucial factors.

Computer Systems and Networks: Device-Aware Interfaces Interfaces must take into account physical constraints of computers and networks: • How does a desktop computer differ from a laptop? • What is special about a smartphone?• How do you make use of a touch-sensitive screen?• What works well with a digital camera? Constraints that the interface must allow for: => performance of device (e.g., fast or slow graphics) => limited form factor (e.g., small display, no keyboard) => connectivity (e.g., intermittent)

Software Eng vs System Eng vs Computer Science

Computer science focuses on theory and fundamentals Software engineering is concerned with the practicalities of developing and delivering useful software. System engineering is concerned with all aspects of computer-based systems development including hardware, software and process engineering. Software engineering is part of this more general process.

Project Planning Tools

Critical Path Method, Gantt charts, Activity bar charts, etc. ØBuild a work-plan from activity dataØ Display work-plan in graphical or tabular form Project planning software (e.g., Microsoft Project) Ø Maintain a database of activities and related data ØCalculate and display schedulesØManage progress reports

Data and Metadata The interface functions and the interface design provide an interface to the data and metadata stored by the computer system.• The desktop metaphor has the concept of associating a file with an application. This requires a file type to be stored with each file: -> extension to filename (e.g., .txt, .pdf) Inexperienced clients sometimes ask for interface features that require additional data or metadata.

Design from a System Viewpoint UI depends on functions provided by underlying software which depend on data structures and metadata that depend on comp systems and networks. From User perspective, all this is called "Mental Model"

Development Processes for User Interfaces It is almost impossible to specify an interactive or graphical interface in a textual document. Requirements benefit from sketches, comparison with existing systems, etc. Designs should include graphical elements and benefit from a mock-up User interfaces must be tested with users Schedules should include user testing and time to make changes Whatever process you use to develop a software system, the development of the user interface is always iterative.

Where are the Risks? Can they be Minimized?

Development risks There must be an outline plan with a rough timetable and staff allocation The plan must have a very large margin for contingencies. (Projects typically require twice the staff and/or time envisioned in the feasibility plan.) Same for budget! External Every system interacts with others. Are the others committed to the necessary efforts (e.g., potential users and customers)? Where are the external pressures and obstacles?

Feasibility Study: Decision

Different organizations and senior managers have different styles for feasibility studies, e.g., some decision makers: Monitor the team and the process Rely on detailed reading of a written report Rely on face-to-face questioning of knowledgeable people But they must understand the decision.

The CRAFT of software development is to select the appropriate methods for each project and apply them

EFFECTIVELY

Equipment Requirements There may also be requirements to support computers with poor performance, limited screen sizes, bad network connections, etc. Be explicit about the equipment assumptions that you make and how to handle failures. Do user testing with both good and bad equipment Example: Mail has a requirement that operations terminate cleanly if the network connection is lost, but its behavior is erratic if the network connection becomes extremely slow, e.g., it will not quit

System design:

Establish a system architecture, both hardware and software, that matches the requirements

Developing a Scenario with a Client

Example of how to develop a scenario with a client The requirements are being developed for a system that will enable university students to take exams online from their own rooms using a web browser Create a scenario for how a typical student interacts with the system Client Developing a scenario with a client clarifies many functional requirements that must be agreed on before a system can be built. The scenario will often clarify the requirements and the user interface, but the design of the user interface should not be part of the scenario Although this scenario is quite simple, many details have been left out.

Example: Game Program - Undo Move The app has to store the previous moves. Interface function is undo a move The UI is a gesture/beep accompanied by board position change

Examples of Mental Models The mental model is the user's model of what the system provides. The computer model may be quite different from the user's mental model Example: The web search Mental model - one vast collection of pages, searched on request Computer model: a central index, which is searched on request

Iterative refinement

Go quickly through all the steps to create a rough system, then repeat them to improve the system -EXAMPLE: Create a prototype system early in the process Review the prototype with clients and test it with users, to improve the understanding of the requirements and clarify the design Refine the prototype in a series of iterations Note: Requirements are hard to understand until there is an operational system, particularly with user interfaces. Mistakes in the requirements are expensive to correct. medium weight process with documentation created during the process Iterative refinement uses various techniques that enable the client to review the planned system early during development: -User interface mock-up -Throw-away software components - Dummy modules Rapid prototyping Successive refinement Get something working as quickly as possible, for client and user evaluation, but do not release it.

Finite State Machine Model State Transition Table

Great model for specifying user interfaces

Requirements Documentation Option 1 - Heavyweight Processes

Heavyweight software process expect detailed specification Written documentation that specifies each requirement in detail Carefully checked by client and developers Maybe a contractual documentDifficulties Time consuming and difficult to create and maintain Checking a detailed specification is difficult and tedious Details may obscure the overview of the requirements Clients rarely understand the implications The difficulty of creating and maintaining a detailed requirements specification is one of the reasons that many organizations are attracted to light weight development processes

How to get Navigation right with User Testing Before building an application, test the navigation. Create simple mock-ups, e.g., rough sketches. Create a large number of simple scenarios. They should show all the main paths through the application, including user mistakes, system problems, etc. Step through the scenarios with the client and potential users. Later in the development process, these scenarios can be used for user interface design, program design, and all forms of testing. It is much easier to make changes in the basic navigation before beginning the detailed user interface design and implementation.

Choosing a Software Process

If the requirements are poorly understood, or expected to change, select a process that keeps flexibility. Iterative refinement, sprints, phased implementation. If a big software systems has many inter-related components, avoid major changes to the design of a system during development. Sequential process, such as the modified waterfall model. If the market for the software is poorly understood, use a process that gets operational software in front of customers as quickly as possible. Incremental, sprints.

Models: Diagrams and Specification in UML

In UML, a model consists of a diagram and a specification. A diagram is the graphical representation of a set of elements, usually represented as a connected graph of vertices (things) and arcs (relationships). Each diagram is supported by technical documentation that specifies in more detail the model in the diagram. A diagram without a specification is of little value.

Information Presentation Simple is often better than fancy Text precise, unambiguous fast to compute and transmit Graphical interface simple to comprehend / learn, but icons can be difficult to recognize uses of color variations show different cases

Interface Design: Menus Easy for users to learn and use Certain categories of error are avoided Enables context-sensitive helpMajor difficulty is structure of large number of choices Scrolling menus (e.g., states of USA) Hierarchical Associated control panels Menus plus command line Users prefer broad and shallow to deep menu systems

Interface Functions The interface functions determine the actions that are available to the user: Select part of an object Search a list or sort the results View help information Manipulate objects on a screen Pan or zoom

Interface Functions There may be alternative user interface designs for the same interface functions, for example: Different versions of the MS Windows desktop have most of the same interface functions, but different user interface designs. Applications that run on both Windows and Macintosh computers support a one button mouse (Macintosh) or a two button mouse (Windows).

Requirements Documentation Option 2 - Lightweight Processes

Lightweight processes use an outline specification + other tools Documentation describing key requirements in appropriate detail Reviewed by client and developers Details provided by supplementary tools, e.g., User interface mock-up or demo Models, e.g., database schema, etc. Clients understand prototypes better than specification Iterative or incremental development proce

Mental Model/Conceptual model A mental model is what a user thinks is true about a system, not necessarily what is actually true. A mental model should be similar in structure to the system that is represented A mental model allows a user to predict the results of his/her actions A mental model is simpler than the represented system. It includes only enough information to allow reasonable predictions A mental model is also called a conceptual model.

Mobile Applications Designers wish to control what the user sees, but users wish to configure their own environments. Client computers and network connections vary greatly in capacity. Client software may run on various operating systems, which may not be the current version. Accessibility requires that designers do not take control of parameters such as font size. Be explicit about the assumptions you make about the user's computer, web browser, etc.

Mobile Applications Designers wish to control what the user sees, but users wish to configure their own environments. Client computers and network connections vary greatly in capacity. Client software may run on various operating systems, which may not be the current version. Accessibility requires that designers do not take control of parameters such as font size. Be explicit about the assumptions you make about the user's computer, web browser, etc. \

Mobile Apps: Conventions Development environments encourage consistent apps. You may never have used this app, but look at how many aspects feel familiar.

Mobile Apps: Conventions Development environments encourage consistent apps. You may never have used this app, but look at how many aspects feel familiar.Mobile Applications Designers wish to control what the user sees, but users wish to configure their own environments. Client computers and network connections vary greatly in capacity. Client software may run on various operating systems, which may not be the current version. Accessibility requires that designers do not take control of parameters such as font size. Be explicit about the assumptions you make about the user's computer, web browser, etc.

Mobile Apps: the Design Challenge How do you design a user interface with no instructions, no user manual, no training? Look: Characteristics of the appearance that convey information. Feel: Interaction techniques that are intuitive and provide satisfactory experience. Metaphors and mental models: Mental models and metaphors. But there may not be an intuitive model. Navigation rules: How to move among data, functions, and activities in a large space. Conventions: Familiar aspects that do not need extra training - good for users, good for designers, e.g., scroll bars, buttons, gestures, help systems, sliders.

Model-View-Controller: The Controller In the Model-View-Controller architecture, the interface functions are invoked by the Controller. The Controller manages the flow of control of the whole user interface and connects the View to the Model.

Model-View-Controller: The Controller In the Model-View-Controller architecture, the interface functions are invoked by the Controller. The Controller manages the flow of control of the whole user interface and connects the View to the Model.Model-View-Controller: The Model • In the Model-View-Controller architecture, the data and metadata are maintained by the Model. • TheModelalsomanagesthelogicofallpartsofthe system that are not part of the user interface.

Model-View-Controller: The Model • In the Model-View-Controller architecture, the data and metadata are maintained by the Model. • TheModelalsomanagesthelogicofallpartsofthe system that are not part of the user interface.

Model-View-Controller: The Model • In the Model-View-Controller architecture, the data and metadata are maintained by the Model. • TheModelalsomanagesthelogicofallpartsofthe system that are not part of the user interface.Mobile Apps: the Design Challenge How do you design a user interface with no instructions, no user manual, no training? Look: Characteristics of the appearance that convey information. Feel: Interaction techniques that are intuitive and provide satisfactory experience. Metaphors and mental models: Mental models and metaphors. But there may not be an intuitive model. Navigation rules: How to move among data, functions, and activities in a large space. Conventions: Familiar aspects that do not need extra training - good for users, good for designers, e.g., scroll bars, buttons, gestures, help systems, sliders.

Model-View-Controller: The View Most modern development environments use one of the many variations of the Model-View-Controller architecture. In the Model-View-Controller architecture, the user interface is called the View. Many of the interface functions are implemented by user interface widgets that are provided by the development environment. The development environment may also provide recommended styles for the user interface, e.g., fonts, Graphical elements.

Modeling Tools: Pseudo- code An informal modeling technique to show the logic behind part of the system. Recommended only in case of technical clients. Otherwise, notation could be confusing to most clients.

Outline of Take Exam Use Case

Name of Use Case: Take Exam Actor(s): ExamTaker Flow of events: ExamTaker connects to the Exam server Exam server checks whether ExamTaker is already authenticated and runs authentication process if necessary ExamTaker selects an exam from a list of options ExamTaker repeatedly selects a question and either types in a solution, attaches a file with a solution, edits a solution or attaches a replacement file Flow of events: ExamTaker either submits completed exam or saves current state When a completed exam is submitted, Exam server checks that all questions have been attempted and either sends acknowledgment to ExamTaker, or saves current state and notifies ExamTaker of incomplete submission ExamTaker logs out Entry Conditions: ExamTaker must have authentication credentials Computing requirements: supported browser

Navigation: Organization of Pages and Screens The organization of the pages must match the user's mental model. Keep it simple. Organization of pages in a web application The basic building block of the web is a hyperlink. This allows any page to link to any other page. This is flexible, but can lead to confusing applications. Many web sites use a hierarchical tree structure. Organization of screens in a mobile app Both Android and iOS encourage the use of a stack based architecture. When a user leave a screen, the state is pushed onto a stack and is available when the screen is next used. Indicate to the user what pages are available and how to reach them.

Networks Operations that transfer data over the network have unpredictable response times and are subject to delay. Large data transfers should run asynchronously in a separate thread. Provide visual feedback to indicate that the operation is in progress. Provide a way for users to cancel long running data transfers.

Feasibility Study: Benefits

Organization benefits Create a marketable product Improve the efficiency of an organization (e.g., save staff) Control a system that is too complex to control manually New or improved service (e.g., faster response to customers) Safety or security Professional benefits are not the reason for doing a project

Principles of User Interface Design User interface design is partly an art, but there are general principles Consistency -- in appearance, controls, and function Feedback -- what is the computer system doing? Why does the user see certain results? Users should be able to interrupt or reverse actions. Error handling should be simple and easy to comprehend. Skilled users should be offered shortcuts; beginners should have simple, well-defined options. The user should feel in control.

Good software requires good programming, but remember:

Programming quality is the means to the END not the END ITSELF

Examples of Mixed Processes: Iterative Refinement + Waterfall Model

Project: Add graphics package to a programming environment Phase 1: Iterative refinement Make several prototype versions by extending the current environment with a preprocessor and run-time support package. Test with users until users are pleased with function. Phase 2: Modified waterfall Use the results of Phase 1 to specify a formal set of requirements. Write new compiler and run-time system incorporating graphics elements. Make minor adjustments to requirements as needed.

Prototyping Requirements Rapid prototyping is the most comprehensive of all modeling methods A method for specifying requirements by building a system that demonstrates the functionalities of key parts of the required system. Particularly valuable for user interfaces

Program design

Represent the software functions in a form that can be transformed into one or more executable programs Preliminary user testing is often carried out as part of the design step Models are used to represent the requirements, system architecture and program design (for ex: UML)

Requirements Definition: Data Dictionaries A data dictionary is a list of names used by the system Name (e.g. "start_date") Brief definition (e.g. what is "date") What is it? (e.g. integer, relation) Where is it used? Etc.. As the system is developed, the data dictionary in the requirements is the basis of the system data dictionary, which is part of the final specification.

Process Step: Requirements

Requirements define the function of the system from the client's viewpoint. The requirements establish the system's functionality, constraints, and goals by consultation with the client, customers, and users self-contained study, or may emerge incrementally basis for acceptance testing The development team and the client need to work together closely during the requirements phase of a software project. understandable by both the client and the development staff

Requirements document variability

Requirements document variability Information in requirements document depends on type of system and the approach to development used. Systems developed incrementally will, typically, have less detail in the requirements document. Requirements documents standards have been designed e.g. IEEE standard. These are mostly applicable to the requirements for large systems engineering projects.

Responsive Web Design The ideal: A single web site adapts to any device by using a mix of flexible grids and layouts, and careful use of CSS media queries. In practice: Mobile devices, such as smartphones, are so different from regular computers that it is extremely difficult to create a web site that works well on all devices. For example: Less content can be displayed on a small screen than on a large screen. Smartphones are usually used in portrait; computer screens are landscape. A touch screen has different characteristics from a mouse, e.g., the user cannot hover over a menu item. A virtual keyboard needs screen space.

Scenarios and Use Cases in the Development Cycle

Scenarios and use cases are both intuitive - easy to discuss with clients Scenarios are a tool for requirement analysis Useful for validating use cases and checking the design of a system They can be used as test cases for acceptance testing Use cases are a tool for modeling requirements A set of use cases can provide a framework for the requirements specification Use cases are the basis for system and program design

Feasibility Study: Scope

Scope expresses the boundaries of the system: It will have a list of included functions It will have a list of excluded functions It will have a list of dependencies It will have a list of current systems to be replaced

Screen Size: Responsive Web Design Responsive web design adjusts how web pages are viewed based on the size of the screen, or other characteristics of the device or browser used to view the page. Media queries in CSS allow the page to use different CSS style rules based on characteristics of the device the site is being displayed on, e.g., the width of the browser window. For example: You develop a web site using a laptop computer. How will it look on a smartphone?

Agile/ Incremental Development

Small increments of software are developed in a sequence of sprints, each of which creates a deployable code Characteristics Development of a project is divided into a large number of sprints Each sprint ends with a fully tested code This is a lightweight process with minimal documentation created during the process General definition of Agile software development: Describes a set of principles for software development under which requirements and solutions evolve through the collaborative effort of self-organizing cross-functional teams - the project is divided into a large number of small tasks, known as sprints For each sprint, a team works through a full software development cycle including planning, requirements analysis, design, coding, testing, and acceptance testing, and release Each sprint is completed in a fixed time period, e.g., four weeks. The size of an sprint is based on team size, e.g., 5-10 people. After each sprint, the code may be: Released (original agile method) Combined with code from other sprints for subsequent release Incorporated into a larger code base When software is released online it is often possible to divide it into small increments that are developed and released in quick succession. Advantages Payback on investment begins soon Requirements are more clearly understood in developing subsequent sprints (minimize waste) Feedback from customers and clients can be incorporated in later phases The challenge of Agile development - The agile approach is excellent for the development or continual enhancement of a system within an established architecture A high-level team must establish the overall architecture and coordinate the sprints Rework With agile development the requirements and design of the overall system emerge incrementally Inevitably parts of some early sprints will need rework This requires changes to code that has been tested and released If the amount of rework is large, it is more efficient not to fully polish each component, but to use iterative refinement to minimize the amount of rework

Smartphones and Tablets: Screen Size Smartphones and tablets have small screens. Every small area is important. There is big difference in screen size between a small smartphone and a large tablet. There may be different layouts or even different versions for different screens. Apps need to have different layouts for portrait and landscape. Apps need to be tested with a full range of screen sizes and orientations. Some apps may be optimized for a large screen. Use a simulator to see how your app looks on various devices.

Smartphones: Accessibility Smartphones have small displays and small virtual keyboards. Some apps rely on speech or other sound signals. People with poor eyesight, color blindness, hearing loss, or clumsy fingers may have difficulty using your applications. Android and iOS provide numerous accessibility features and provide online advice about how to build accessible apps. For your user testing try to find people who do not have perfect eyesight, hearing, etc. Have testers of various ages.

Terminology User Experience (UX) The user experience is the total of all the factors that contribute to the usability (or otherwise) of a computer and its systems Human Computer Interaction (HCI) Human Computer Interaction is the academic discipline that studies how people interact with computers

The Importance of User Interface Design A computer system is only as good as the experience it provides to its users. Appropriate functionality, easy navigation, elegant design, and fast response time makes a measurable difference to a system's effectiveness If a system is hard to use: Users may fail to find important results, or misinterpret what they do find Users may give up Usability is more than user interface design Developing good user interfaces needs skill and time

Scrum Master

The Scrum Master is responsible for ensuring that the Scrum process is followed and guides the team in the effective use of Scrum. He or she is responsible for interfacing with the rest of the company and for ensuring that the Scrum team is not diverted by outside interference. The Scrum developers are adamant that the Scrum Master should not be thought of as a project manager. Others, however, may not always find it easy to see the difference.

Principles of Modeling

The choice of what models to create has a profound influence on how a problem is attacked and how a solution is shaped No single model is sufficient. Every nontrivial system is best approached through a small set of nearly independent models Every model can be expressed at different levels of precision Good models are connected to reality

Acceptance testing

The client tests the final version of the system or parts of the system against the requirements.

Lightweight process

The development team releases working software in small increments, and develops the plans incrementally, based on experience. Each increment includes all the process steps. There is expectation that changes will be made based on experience. [example: Agile Software Development] --the deliverables are incremental working code, with minimal supporting documentation

Program testing

The development team tests components individually (unit testing) or in combination (system testing) against the design to find bugs, etc.

Heavyweight process

The development team works through the steps slowly and systematically, with the aim of fully completing each step and delivering a complete software product that will need minimal changes and revision [example: modified waterfall model] --each process step creates a deliverable, usually documentation, ex: requirements specification

Feasibility Study: Planning and Resources

The feasibility study must include an outline plan: Estimate the staffing and equipment needs, and the preliminary timetable Identify major milestones and decision points Identify interactions with and dependencies on external systems Provide a preliminary list of deliverables and delivery dates

Techniques for Feasibility Studies

The highest priority is to ensure that the client and development team have the same understanding of the goals of the system. For the development team to understand the goals: Interviews with client and the staff of the client's organization Review of existing systems (including competitors')For the client to appreciate the proposed system: Demonstration of key features or similar systems Mock-up of user interfaces Walk through typical transactions or interactions Outline budget: n people for m months at $x per month Equipment, buildings, etc. Contingency (at least 50% is needed) Phases/milestones: Specify deliverables and approximate dates Planned release

Visibility

The people who take responsibility must know what is happening

Requirements engineering processes

The processes used for RE vary widely depending on the application domain, the people involved and the organisation developing the requirements. However, there are a number of generic activities common to all processes Requirements elicitation; Requirements analysis; Requirements validation; Requirements management. In practice, RE is an iterative activity in which these processes are included.

The user interface is the appearance on the screen and the actual manipulation by the user Fonts, colors, logos, key board controls, menus, buttons Mouse control, touch screen, or keyboard control Conventions (e.g., "back", "help")

Tools for Usability Requirements: Focus Group A focus group is a group interview: Interviewer Potential users: typically 5 to 12 with similar characteristics Structured set of questions May show mock-ups Group discussions Repeated with contrasting user groups

The Unified Modeling Language (UML)

UML is a standard language for modeling software systems Serves a bridge between the requirements specification and the implementation Provides a means to specify and document the design of a software system Is process and programming language independent Is particularly suited to object-oriented program development

Challenges of feasibility studies

Uncertainty Challenges Clients may be unsure of the scope of the project Benefits are usually very hard to quantify Approach is usually ill-defined. Estimates of resources and timetable are very rough Organizational changes may be needed (hard to predict)Therefore, feasibility studies rely heavily on the judgment of experienced people. Mistakes made at the beginning of a project are the most difficult to correct. Advocacy Challenges Advocacy is needed to build enthusiasm for a project: to convince an organization to undertake an expensive, complex project with many risks. Enthusiasm is good, but enthusiasts usually emphasize potential benefits and downplay risks. People carrying out the feasibility study and making the decision often have a vested interest in the project going ahead, e.g., financial gain, career development.

Usability and Cost User interface development may be a major part of a software development project Good usability may be expensive in hardware or special software development Costs are multiplied if a user interface has to be used on different computers or migrate to different versions of systems Design users interfaces that can be built with standard tools: Web browsers provide a general purpose user interface where others maintain the user interface software. Use the standard classes that the development environment provides.

Gantt Charts

Used for small projects, single time-boxes, and sprints Dates run along the top (days, weeks, or months) Each row represents an activity. Activities may be sequential, in The schedule for an activity is a horizontal bar. The left end marks the planned beginning of the task. The right end marks the expected end date. The chart is updated by filling in each activity to a length proportional to the work accomplished Progress to date can be compared with the plan by drawing a vertical line through the chart at the current date

User Interface Design Example: to leave full screen Keyboard: escape key, control-F Icons - Mouse/touch: Examples of design choices Screen space utilization in Adobe Reader (text vs. controls). Number of snippets per page in web search (google uses 4 lines per snippet)

User Interface Design: Navigation Getting the navigation right is central to the user experience. Applications consist of one or more pages (web) or screens (mobile apps). Web: loading a new page uses the network and is therefore slow Smartphone or tablet: loading a new screen is usually instantaneous The first step in user interface design is to choose what pages or screens to use. What functionality is provided on each screen? How are the screens organized? How does the user know what screens are available? How does the user move between screens?

Command line interfaces (CLI)

User interacts with computer by typing commands (e.g., Linux shell script) Allows complex instructions to be given to computer Facilitates formal methods of specification & implementation Skilled users can input commands quickly Unless very simple, requires learning or training Can be multi-lingual Suitable for scripting / non-human clients

User interacts with computer by typing commands (e.g., Linux shell script) Allows complex instructions to be given to computer Facilitates formal methods of specification & implementation Skilled users can input commands quickly Unless very simple, requires learning or training Can be multi-lingual Suitable for scripting / non-human clients graphical interfaces (GUI) graphical representation in which the users can interact with software or devices through graphical icons. Not suitable for some complex interactions new users will pick up a GUI much faster May be slow for skilled users Difficult to build scripts control over files and the operating system Only suitable for human users

Types of requirement

User requirements Statements in natural language plus diagrams of the services the system provides and its operational constraints. Written for customers. System requirements A structured document setting out detailed descriptions of the system's functions, services and operational constraints. Defines what should be implemented so may be part of a contract between client and contractor.

User testing

Versions of the user interface are tested by users. Their experience may lead to changes in the requirements or the design.

Key Points PART

What are user requirements and system requirements? User requirements are statements in a language that is understandable to a user of what services should provide and the constraints under which it operates. System requirements are more detailed descriptions of the system services and constraints, written for developers of the system. What is the distinction between functional and non- functional requirements? Functional requirements define what the system should do. Non- functional requirements are not directly concerned with specific system functions but specify required system properties or place constraints on the system or its development process. What is the software requirements document? The official document that defines the requirements that should be implemented by the system developers. Give 5 reasons why eliciting requirements is difficult? Stakeholders don't know what they want Stakeholders use their own language that requirements engineers may not understand. Stakeholder requirements may conflict Political factors may influence the system requirements The business environment may change during elicitation. What UML diagram types do you need to represent the essential features of a system? Activity diagrams, Use case diagrams, Sequence diagrams, Class diagrams, State diagrams What are the principal stages of the requirements engineering process? Requirements elicitation and analysis Requirements specification Requirements validation What is the distinction between the terms' shall' and 'should' in a user requirements document, which is written in natural language? ʻShallʼ normally indicates a mandatory requirement ʻShouldʼ indicates a desirable but not essential requirement. What is a use-case? A use-case identifies a typical interaction with a system and the actors (human or computer) involved in that interaction. List 3 types of non-functional requirement? Product requirements, that specify or constrain the software's behavior. Organizational requirements, are general requirements derived from policies and procedures in the customer's organization. External requirements, which cover all requirements derived from factors external to the system and its development process. What perspectives should be used for system modelling? An external perspective An interaction perspective A behavioral perspective A structural perspective.

Why is it challenging?

With experienced staff, estimating the actual time to carry out a single task is usually fairly accurate, but ... The little bits and pieces are underestimated: Ø The time from almost "done" to completely "done" is much longer than anticipated. (There's just one thing to tidy up. I need to put the comments into better shape. I really should get rid of that patch.) Ø The distractions are not planned for. (My system crashed and I decided to upgrade the software. My child's school was closed because of snow. I spent the day interviewing job candidates.) Ø Some things have to be done twice.

Requirements in the Modified Waterfall Model

cotuniual updates as project continues

Requirements

define the function of the system from the client's viewpoint. The requirements establish the system's functionality, constraints, and goals by consultation with the client, customers, and users. Failure to agree on the requirements and define them adequately is one of the biggest causes of software projects failing.

Design

describes the system from the software developers' viewpoint

Requirements with Incremental Development

each spring has own reqs

Software engineering

engineering discipline that is concerned with all aspects of software production (Design, development and maintenance)

Usability

great importance in many modern applications and software systems. That requires good user interface design. User interfaces need to be evaluated with users.

Mental Model vs. Computer Model he mental model is that the photograph is but in the computer model the photograph is embedded in the text of the document... an independent file, which could be changed separately.

he mental model is that the photograph is but in the computer model the photograph is embedded in the text of the document... an independent file, which could be changed separately.

Good software should deliver the

required functionality and performance to the user and should be maintainable, dependable and usable

Requirements in Iterative Refinement

revised for each iteration

Functionality, Cost, Time

trade off

Terminology

Ø Deliverable Terminology Work product that is provided to the client (mock-up, demonstration, prototype, report, presentation, documentation, code, etc.) Release of a system or subsystem to customers or users Ø Milestone Completion of a specified set of activities (e.g., delivery of a deliverable, completion of a process step) Ø Activity (or Task)Ø Part of a project that takes place over time ØEventØ The end of a group of activities, e.g., agreement by all parties on the budget and plan Ø Dependency Ø An activity that cannot begin until some event is reached Ø Resource Ø Staff time, equipment, or other limited resources required by an activity

Project Plans

Ø For a plan-driven development project: Ø A project plan sets out the resources available to the project, the work breakdown and a schedule for carrying out the work. Ø Plan Sections Introduction Project organization Risk analysis Hardware and software resource requirements Work breakdown Project schedule Monitoring and reporting mechanisms

Plan-driven Development

Ø Plan-driven or plan-based development is an approach to software engineering where the development process is planned in detail. Ø Plan-driven development is based on engineering project management techniques and is the 'traditional' way of managing large software development projects. Ø A project plan is created that records the work to be done, who will do it, the development schedule and the work products. Ø Managers use the plan to support project decision making and as a way of measuring progress. Ø Pros: Ø Early planning allows organizational issues (availability of staff, other projects, etc.) to be closely taken into account, Ø Potential problems and dependencies are discovered before the project starts, rather than once the project is underway. Ø Cons: Ø Many early decisions have to be revised because of changes to the environment in which the software is to be developed and used.

Project Scheduling

Ø Process of deciding Ø how the work in a project will be organized as separate tasks Ø When and how these tasks will be executed ØEstimate the: Ø Calendar time needed to complete each task, Ø Effort required to finish the task Ø People working on the task Ø Resources needed for each task (ex. disk space required on a server, the time required on specialized hardware such as a simulator, travel budgets,..etc) Split project into tasks and estimate time and resources required to complete each task. Organize tasks concurrently to make optimal use of workforce. Minimize task dependencies to avoid delays caused by one task waiting for another to complete. *Dependent on project managers intuition and experience.*

Aspects of Project Management

Ø Project planning Ø Project managers are responsible for planning. estimating and scheduling project development and assigning people to tasks. ØRisk management Ø Project managers assess the risks that may affect a project, monitor these risks and take action when problems arise. ØPeople management Ø Project managers have to choose people for their team and establish ways of working that leads to effective team performance.Ø Reporting Ø Project managers are usually responsible for reporting on the progress of a project to customers and to the managers of the company developing the software. ØProposal writing Ø The first stage in a software project may involve writing a proposal to win a contract to carry out an item of work. The proposal describes the objectives of the project and how it will be carried out. Planning Outline schedule during feasibility study Fuller schedule for each part of a project (e.g., each process step, iteration, or sprint) Contingency planning Anticipation of possible problems (risk management) Progress tracking Regular comparison of progress against plan Regular modification of the plan Final analysis Analysis of project for improvements during next project

Standard Approach to Project Management

Ø The scope of the project is defined early in the process Ø The development is divided into tasks and milestones Ø Estimates are made of the time and resources needed for each task Ø The estimates are combined to create a schedule and a plan Ø Progress is continually reviewed against the plan, perhaps weeklyØ The plan is modified by changes to scope, time, resources, etc. Typically the plan is managed by a separate project management team, not by the software developers

Team-based Estimating

Ø The team often has the best understanding of what it can achieve in a single time-box or sprint Ø The team commits to the outcome of a sprint Ø The team must have an internal schedule to allocate tasks within a sprint

Project Startup Planning

ØAt this stage, you know more about the system requirements but do not have design or implementation information ØCreate a plan with enough detail to make decisions about the project budget and staffing. Ø This plan is the basis for project resource allocation ØThe startup plan should also define project monitoring mechanisms ØA startup plan is still needed for agile development to allow resources to be allocated to the project

Factors Influencing project management

ØCompany sizeØSoftware customersØSoftware sizeØSoftware typeØOrganizational culture ØSoftware development processes These factors mean that project managers in different organizations may work in quite different ways.

PROJECT MANAGEMENT

ØConcerned with activities involved in ensuring that software is delivered on time and on schedule and in accordance with the requirements of the organisations developing and procuring the software. ØProject management is needed because software development is always subject to budget and schedule constraints that are set by the organisation developing the software.

The Aim of Project Management

ØDeliver the software to the customer at the agreed time. ØKeep overall costs within budget.ØDeliver software that meets the customer's expectations. ØMaintain a coherent and well-functioning development team. Ø To provide visibility about the progress of a project

Schedule presentations

ØGraphical notationsØ Project breakdown into tasks Ø Calendar-basedØ Bar charts are the most common way. (shows activities or resources against time) ØActivity networksØ Show task dependencies

Proposal Planning

ØPlanning may be necessary with only outline software requirements. Ø The aim of planning at this stage is to provide information that will be used in setting a price for the system to customers. ØProject pricing involves estimating how much the software will cost to develop, taking factors such as staff costs, hardware costs, software costs, etc. into account

Project Planning

ØProject planning involves breaking down the work into parts and assign these to project team members, anticipate problems that might arise and prepare tentative solutions to those problems. Ø The project plan, which is created at the start of a project, is used to communicate how the work will be done to the project team and customers, and to help assess progress on the project.

Development Planning

ØThe project plan should be regularly amended as the project progresses and you know more about the software and its development ØThe project schedule, cost-estimate and risks have to be regularly revised

Scenarios for Analyzing Special Requirements

❖ Scenarios are very useful for analyzing special requirements. Examples Reversals: in a financial system, a transaction is credited to the wrong account. What sequence of steps are used to reverse the transaction? Errors: a mail order company has several copies of its inventory database. What happens if they become inconsistent? Malfeasance: in a voting system, a voter has houses in 2 cities. What happens if he attempts to vote in both of them? Scenarios for error recovery Murphy's Law: "if anything can go wrong, it will". Create a scenario for everything that can go wrong and how the system is expected to handle it.

software engineering principles

संबंधित स्टडी सेट्स

Oceanography Chapter 14

CH 14 Pathopharm

Chapter 24 quiz

Growth and development of the toddler - Chapter 4 Peds

CHEM Chapter 10 Chemical bonding II: molecular geometry

PHARM Reproductive and Genitourinary Systems

Finance Final

PROFESSIONAL PRACTICE REFRESHER

PANGAHALIP

digestive system secretion study

Chapter 1

Pre-AP World History Second Semester Study Guide 2022

Personal Finance Chapter 4

Chapter 7: Exponents

BUL3130 IRSC Ch 2 quiz

Advanced Math Vocabulary

Math Chapter (3)

W!SE Vocabulary

Exam 2

Chapter 4 Physics review questions