Avatar of admin

by admin

CPU, Registers, Condition Code Bits and Addressing Modes

October 21, 2007 in Computer Architecture 2

CPU Registers

Accumulators A, B, and D – There are two 8-bit accumulators A and B. These accumulators can be concatenated such that the two 8-bit accumulators are treated as a single 16-bit accumulator named D. Therefore any changes to D also modify A and B. Accumulator A is the most significant octet of D. The accumulator registers are used for storing intermediate arithmetic and logic results which without accumulator registers, would need to be written to main memory after each calculation. Access to main memory is slower than access to registers, so the use of registers is very important, especially if the value calculated is to be used again immediately in the next operation.

Index Registers X and Y – The X and Y registers are both 16-bit index registers used primarily as pointers or indexed addressing. Also used by arithmetic instructions.

Stack Pointer – The stack pointer is used to make sub-routines possible. By always pointing to the last used memory location, a push command can be used to add onto the stack and a pull to retrieve the last operation. Therefore, before executing a set of instructions, the current address can be pushed to the stack and at the end of the execution of the set of instructions, the address can be pulled from the stack making it possible to return to the previous location. The stack pointer must be initialized before it can be used.

Program Counter - Programmers do not have direct control over the program counter like they do with other registers. The program counter indicates where the CPU is in its current instruction sequence.

Condition Code Register – Contains flags set by the processor during the execution of instructions.

HCS12 Condition Code Register Bits (Table 4.2 From [1])

Bits Modified by Various Instructions

Bit Flag Conditions for Setting
0 C If a carry or borrow occurs
1 V If a two’s complement overflow occurs
2 Z If the result is zero
3 N If the most significant bit of the result is set
5 H This is the half-carry bit and is set if a carry or borrow out of bit 3 of the result occurs

Bits Associated with HCS12 Control

Bit Flag Conditions for Setting
4 I Interrupt mask
6 X X interrupt mask
7 S Stop disable

HCS12 CPU[2]

C – Carry/Borrow Bit

Overflow/Underflow – The result of the addition or subtraction is too big or too small to be represented with the available bits.

The C bit is set to 1 if an addition produces and overflow or if a subtraction produces an underflow.

V – 2′s Complement Overflow

The carry bit cannot indicate an overflow for signed 2′s complement numbers. This is why the V bit is necessary for such cases. An overflow with with 2′s Complement Numbers is not possible when both numbers have different signs. To determine the value of the V bit, the following algorithm can be used:

  • Check that both numbers have the same sign
  • If the sign of the result of the addition or subtraction gives a different sign, then overflow occurred and the V bit should be set to 1.

N – Sign Bit

Takes the value of the most significant bit in the calculated result. If using signed 2′s complement, then the N bit indicates the sign of the calculated result.

Z – Zero Bit

The Z bit is set to 1 when the value of the calculated result is equal to zero.

H – Half Carry Bit

The H bit is set to 1 when a carry or borrow takes place at bit number 3 of the result.

How the CCR (Condition Code Register) Bits are Used

As explained above, the CCR bits are set to either 0 or 1 during the execution of various instructions. Branching instructions then use the values of the CCR bits in order to determine whether or not to branch.

For example, we could use “bne” (Branch if Not Equal) after doing a comparison of two numbers. The “bne” will check the value of the “Z” bit, which will be set to 1 if the result of the comparison was 0 (indicating no difference between the compared numbers meaning they are the same). So, if the Z bit = 1, no branch will occur, but if the Z bit = 0 (branch if not equal), the execution will branch.

Understanding Memory

Physical Address – The address of the memory cell

Segment Address – The location of a block of memory

Offset – The offset is a number representing the size of the segment. Given a segment address (pointing to the start of the address) the offset tells us how long the segment is so we know where it ends.

Logical Address – The logical address is the address used by the program which can then be translated into a physical address. A table will define how logical addresses are associated with physical addresses.

Effective Address – The effective address is calculated by the processor and can be either a physical or logical address.

The MC68HCS12 uses 16 bit addresses. Therefore 2^16 = 64KB address space.

Addressing Modes

Inherent – This type of addressing means that all data for the instruction is within the CPU.

Immediate Addressing – The operand is a known constant and the data immediately follows the instruction. Immediate addressing can be used to initialize registers with constants. The # sign is used to tell the assembler that immediate addressing mode is being used. The # symbol must appear before the operand. (Ex: ldaa #$32 will put hexadecimal 32 into register A)

Direct Addressing – The operand following the op code contains the address in memory. Can address an operand in the first 256 bytes of memory ($0000-$00FF).

Extended Addressing – Uses a 16-bit address to specify a location in the entire 64kb address space. (Direct addressing uses 8-bits, therefore can only address the first 256 bytes). Extended addressing instructions require 3 bytes.

Indexed Addressing – The effective address will be the sum of a 5-, 9-, or 16-bit signed constant and the contents of either the X, Y, SP, or PC register.

Table 4-6 Summary of HCS12 Indexed Operations [1]

Operand Syntax Comments
ldaa ,r 5-, 9-, or 16 bit signed constant offset
ldaa n,r n=-16 to +15 for 5-bit offset
n=-256 to +256 for 9-bit offset
n=-32768 to +32767 for 16-bit offset
r= X,Y,SP, or PC
ldaa n, -r n= 1 to 8 and is subtracted from the contents of register r before the data value is fetched
ldaa n, +r n=1 to 8 and is added to the contents of register r before the data value is fetched
ldaa n, r- n=1 to 8 and is subtracted from the contents of register r after the data value is fetched
ldaa n, r+ n=1 to 8 and is added to the contents of register r after the data value is fetched
ldaa A, r
B, r
D, r
The contents of accumulator A, B, or D are used as a 16-bit unsigned offset
ldaa [n, r] Rather than store r + n -> A, r + n will give an address, and the contents at this address will be stored in A
ldaa [D, r] Same as above, but using D instead of n

Indirect Addressing – An instruction gives an address which points to a location in memory which contains another address. This second address is the address of where the data is stored.

Relative Addressing – Relative addressing is used for branch instructions (jump instructions use extended or indexed addressing). For relative addressing, the assembler calculates the offset automatically based on the label to which we wish to branch. PC + offset = address of next instruction when branching is used.

Stack Addressing – When branching to a sub-routine (BSR), the return address is placed on the stack. The return address is the address of the instruction following the the branch instruction. At the end of the sub-routine the return instruction (RTS) will pull the return address from the stack which will update the Program Counter (PC) with the return address.

[1] Fredrick M. Cady, Software and Hardware Engineering: Assembly and C Programming for the Freescale HCS12 Microcontroller
[2] Prof. Gilbert Arbez, University of Ottawa CSI3531 Course Notes, Module 2

Avatar of admin

by admin

Computers, Microprocessors, Microcomputers, Microcontrollers

October 20, 2007 in Computer Architecture 2

NOTE: This course gives specific information and examples for the Freescale HCS12 Microcontroller.

The below image represents a computer system based on the von Neumann architecture. The HCS12 microcontroller is a von Neumann architecture machine.

Von Neumann Computer System[2]

The term microprocessor first came into use at Intel in 1972 and generally refers to the implementation of the central processor unit functions of a computer in a single, large scale integrated circuit. A microcomputer is a computer built using a microprocessor and a few other components for the memory and I/O.

A microcontroller is a microcomputer with its memory and I/O integrated into a single chip. In 2004, the industry delivered 6.8 billion microcontroller units. [1]

Important Notation: [1]

$ Hexadecimal numbers are denoted by a leading $: For example, $FFFF is the hexadecimal number FFFF. When two memory locations are to be identified, the starting and ending adresses are given as $FFFE:FFFF.

% Binary numbers are denoted by a leading %: for example, $F may be written as %1111.

@ A base-8 octal number is preceded by @: for example $F = @17

# A # indicates immediate addressing mode.

x An x indicates a don’t care bit. x could be either 0 or 1.

A computer is not some sort of mystical creature that is beyond comprehension. It is a human made device composed of basic digital logical components that anybody could design.

A typical microcontroller consists of the following elements: [1]

  • A central processor unit (CPU) that contains registers, an arithmetic and logic unit (ALU), and a sequence controller to control all activities of the microcontroller.
  • Read only memory (ROM) to hold a program and any constant data. Modern microcontrollers have reprogrammable types of read only memory such as flash memory, which is a particular type of electrically erasable programmable read only memory (EEPROM).
  • Random access memory (RAM) to store variable data.
  • An input/output (I/O) interface to connect the micrcontroller to the real world. The I/O interface in most microcontrollers contains other useful functions such as timers, pulse-width modulators, and other special I/O functions.

When a program is written in a high-level language like C or C++ it must then be converted to bytes representing the operation that must be done and the operands that are being operated upon. There is a unique code for each operation to be executed by the microcontroller. For example:

CF 0A 00

The above is an example of instruction code bytes. All addresses and instruction code bytes are in hexadecimal format which will then be translated to binary format.

In the above example, the instruction code bytes correspond to the following in Assembly code: LDS #$0A00. CF is the opcode byte for LDS and the following two bytes 0A 00 are the bytes for the operands.

A computer instruction is the combination of an operation (what the computer is to do) and zero, one, or more operands (what the computer is going to do it to). Again, given the above example, the instruction tells the microcontroller to load or initialize the stack pointer register with the value $0A00.

The central processing unit (CPU) contains registers. There are accumulator registers and registers used to access memory.

Accumulators A and B: The two 8-bit accumulators, A and B, may be a source or destination operand for 8-bit instructions. for example, if we were to retrieve a byte of data from memory we may put it in accumulator A or B. The registers are called accumulators because the results of an arithmetic or logic operation may accumulate there.

Program Counter (PC): Although the program counter is usually shown in the programmer’s model, the programmer does not have direct control over it like the other registers. The number of bits in the program counter shows how much memory can be directly addressed.

Index Register: The program may use an index register to access memory. As we will see when we find out more about the HCS12 microcontroller, there are a variety of instructions that access memory using this type of register.

The Instruction Execution Cycle [1]

The process by which the microcontroller executes each instruction in a program is called the instruction cycle. When an instruction opcode is to be fetched from ROM, the memory must be supplied with the address of the opcode and the read control signal asserted. This is how the instruction cycle starts and it continues by fetching the rest of the instruction bytes, doing whatever is required by the instruction, incrementing the program counter to point to the next opcode, and then repeats.

  • The CPU’s program counter contains the address of the first byte of the instruction to be executed. We say the program counter points to the opcode. The CPU places that address on the address bus.
  • The sequence controller asserts the Read control signal on the control bus.
  • After a small delay, called the memory access time, the ROM places the contents of the addressed memory location on the data bus.
  • The sequence controller writes this byte into the instruction decoder.
  • The instruction decoder holds the opcode byte and decodes it for the sequence controller.
  • The decoded instruction causes the sequence controller to go through a sequence of actions that complete the execution on the instruction. These include fetching operands from memory, loading registers, performing an arithmetic or logical operation on a pair of operands, and incrementing the program counter.
  • When the instruction execution is complete, the program counter is pointing to the next opcode to be fetched and executed. The instruction execution cycle then repeats.

The instruction execution cycle continues forever, or at least until the power is turned off or a special instruction that stops it is encountered.

Instruction Cycle[2]

Sequence Controller [1]

The sequence controller generates control signals required by the currently executing instruction, at the correct time, to accomplish the information transfer operation. The sequence controller is designed to allow different instructions to be executed in different amounts of time. For example, take an 8-bit immediate addressing instruction that transfers a byte from the memory immediately following the opcode byte to some register in the CPU. In the freescale HCS12 instruction set this could be the instruction that loads accumulator A with the data $22.

ldaa #$22

At the start of the instruction execution cycle, the program counter is pointing at the opcode, and the execution cycle starts by fetching the opcode. Next the program counter will be incremented, the byte will be transferred from memory to the register and the program counter will be incremented again to point to the next opcode. This process will then repeat as the execution cycle will start be fetching the next opcode, etc…

Arithmetic and Logic Unit (ALU)

The ALU contains the digital logic to operate on operands in the way specified by the opcode. It does arithmetic, logic and other operations such as shifts, rotates, increments, and decrements. The ALU receives inputs from the accumulator registers and the data bus and places its outputs to accumulator registers and the data bus. [1]

System Structure[2]

[1] Fredrick M. Cady, Software and Hardware Engineering: Assembly and C Programming for the Freescale HCS12 Microcontroller
[2] Prof. Gilbert Arbez, University of Ottawa CSI3531 Course Notes, Module 1

Avatar of admin

by admin

HelloWorld.asm

October 20, 2007 in Computer Architecture 2, Source Code

The following file is the source code required to print “Hello World” to the screen using assembly.

Avatar of admin

by admin

The Oldest Profession in the World

October 1, 2007 in Software Engineer Humor

A doctor, a civil engineer, and a software engineer were arguing about what was the oldest profession in the world. The doctor remarked “Well, in the Bible it says that God created Eve from a rib taken from Adam. This clearly required surgery so I can rightly claim that mine is the oldest profession in the world.”

The civil engineer interrupted and said “But even earlier in the book of Genesis, it states that God created the order of the heavens and the earth from out of the chaos. This was the first and certainly the most spectacular application of civil engineering. Therefore, fair doctor, you are wrong; mine is the oldest profession in the world.”

The software engineer leaned back in his chair, smiled, and said confidently, “Ah, but who do you think created the chaos?

Thank you MC Leong for this one!

Avatar of admin

by admin

What goes up a hill with three legs, and comes down on four?

October 1, 2007 in Software Engineer Humor

A programmer and a software engineer are sitting next to each other on a long flight from San Jose to Bangalore. The programmer leans over to the software engineer and asks if he would like to play a fun game. The software engineer just wants to take a nap, so he politely declines and rolls over to the window to catch a few winks.

The programmer persists and explains that the game is real easy and great fun. He explains “I ask you a question, and if you don’t know the answer, you pay me $10. Then you ask me a question, and if I don’t know the answer, I’ll pay you $10.”. Again, the software engineer politely declines and tries to get to sleep. The programmer, now some what agitated, says, “OK, if you don’t know the answer you pay me $10, and if I don’t know the answer, I’ll pay you $100!” This catches the software engineer’s attention, and he sees no end to this torment unless he plays, so he agrees to the game. The programmer asks the first question. “What’s the distance from the earth to the moon?” The software engineer doesn’t say a word, but reaches into his wallet, pulls out a ten dollar bill and hands it to the programmer. Now, it’s the software engineer’s turn. He asks the programmer “What goes up a hill with three legs, and comes down on four?”

The programmer looks up at him with a puzzled look. He takes out his laptop computer and searches all of his references. He taps into the air phone with his modem and searches the net and the Library of Congress. Frustrated, he sends e-mail to his co-workers all to no avail. After about an hour, he wakes the software engineer and hands him $100. The software engineer politely takes the $100 and turns away to try to get back to sleep. The programmer, more than a little miffed, shakes the software engineer and asks “Well, so what’s the answer?”

Without a word, the software engineer reaches into his wallet, hands the programmer $10, and turns away to get back to sleep.

Thank you John McCormick for this one!

Avatar of admin

by admin

People for the Ethical Treatment of Software (PETS)

October 1, 2007 in Software Engineer Humor

NEW YORK – People for the Ethical Treatment of Software (PETS) announced today that more software companies have been added to the groups “watch list” of companies that regularly practice software testing.

“There is no need for software to be mistreated in this way so that companies like these can market new products,” said Ken Granola, a spokesman for PETS. “Alternative methods of testing these products are available.”

According to PETS, these companies force software to undergo lengthy and arduous test – often without rest – for hours or days at a time. Employees are assigned to “break” the software by any means necessary and inside sources report that they often joke about “torturing” the software.

“It’s no joke,” Granola said. “Innocent programs, from the day they are compiled, are cooped up in tiny rooms and ‘crashed’ for hours on end. They spend their whole lives on dirty, ill-maintained computers, and they are unceremoniously deleted when they’re not needed anymore.”

Granola said that the software is kept in unsanitary conditions and is infested with bugs.

“We know alternatives to this horror exist,” he said, citing industry giant Microsoft Corp. as a company that has become successful without resorting to software testing.

Thank you John McCormick for this one!

Avatar of admin

by admin

Stuck on a Mountain with No Brakes

October 1, 2007 in Software Engineer Humor

A software engineer, a hardware engineer and a department manager were on their way to a meeting in Switzerland. They were driving down a steep mountain road when suddenly the brakes on their car failed. The car careened almost out of control down the road, bouncing off the crash barriers, until it miraculously ground to a halt scraping along the mountainside.

The car’s occupants, shaken but unhurt, now had a problem: they were stuck halfway down a mountain in a car with no brakes. What were they to do?

“I know,” said the department manager, “Let’s have a meeting, propose a Vision, formulate a Mission Statement, define some Goals and by a process of Continuous Improvement find a solution to the Critical Problems, and we can be on our way.”

“No, no,” said the hardware engineer, “That will take far too long, and besides, that method has never worked before. I’ve got my Swiss Army knife with me, and in no time at all I can strip down the car’s braking system, isolate the fault, fix it and we can be on our way.”

Well,” said the software engineer, “Before we do anything, I think we should push the car back up the road and see if it happens again.”

Thank you John McCormick for this one!

Avatar of admin

by admin

Software Size Estimation

September 30, 2007 in Software Project Management

Software Project Estimation [1]

  • You can’t manage something which you can’t measure
  • We need some sort of measurement for:
    • size of the project
    • effort and cost
  • Estimating software projects is notoriously poor.
  • If performance doesn’t meet estimates then either:
    • the performance was poor; or
    • the estimate was poor

Impact on Development Process [1]

  • One of the key factors in software project management
  • If “software managers and engineers are trained in and apply software estimating and planning procedures”, then you are one step closer to CMM level 2 (repeatable).

Lines of Code [1]

  • The most commonly used size indicator, but obviously not the best one!
  • Issues:
    • How can lines of code be defined?
    • How can the total lines of code be known before coding?
    • How interpret lines of code? Is 250 more productive than 200?
    • What about different programming languages which have a different syntax?

Lines of Code Calculation [1]

  • Prerequisite for line of code calculations is the work breakdown structure
  • Line = statement
  • Line = data definition
  • Line != comments
  • Line != debug code
  • Line != test cases
  • For different languages, convert all to assembly.

Beta Distribution Measurement [1]

  • Ask developers for the following line of code values:
  • Optimistic (0)
  • Pessimistic (P)
  • Realistic (R)

LOC = (O+P+4*R)/6

  • ex: R=250, O=200, P=400
    • LOC = 266

The Blitz [1]

  • Based on historical observation of previous projects.

LOC = Processes * prgs/processes * avg. prg size

  • Process = class, db table, …
  • Ex: 20 classes, 1 program/class, 50 java lines of code/program
    • LOC = 20*1*50 = 1000

Wideband Delphi [1]

  • Based on the experience of developers
  1. Gather experts
  2. Conduct group discussion
  3. Gather estimates
  4. Distribute estimates
  5. Repeat until consensus is reached
  • Pros:
    • Takes advantage of experience
    • educates developers about the software
    • reinforces team concept

Function Points [1]

  • Uses the functionality of the software as a measure of its complexity.
  • Analogy: For a given house, we can say how many square meters it has (lines of code) or we can say how many bedrooms and bathrooms it has (function points).
  • A measure of the functionality of a given software.
  • Works best for traditional applications; not very suitable for algorithmically intensive applications. (ex: real-time and embedded applications)

Weighting Factor [1]

  • There are tables that provide the project manager with a weighting factor for each category.
  • Input can be:
    • Simple (weighting factor=4)
    • Average (weighting factor=5)
    • Complex (weighting factor=7)
  • Ex: 1 to 5 data items referenced from 1 file is considered a simple function. Same action from 5 files is considered average.
  • Sum of all weighted categories is the raw function points.

Environmental Factors [1]

  • Data Communications
  • Distributed Computing
  • Performance Requirements
  • Constrained Configuration
  • Transaction Rate
  • Re-usability
  • Ease of Operation
  • And much more…
  • For a given project, each factor is rated from 0 (no effect) to 5 (highly affects).
  • Sum of all gives the environmental influence factor (N)

Adjustments

  • Complexity Adjustment Factor (CAF)
    • Assumes a +-35% inaccuracy in early estimates; therefore:

CAF = 0.65 + 0.01*N

  • Adjusted Function Points (AFP)

AFP = CAF * rawFunctionPoints

  • Convert to lines of code using tables

Differences with Function Point [1]

  • Also includes number of algorithms
    • weighting factor for an algorithm is 3
  • Uses average weighting factors instead of simple, average, and complex values.
  • Uses 2 environmental factors: logical complexity and data complexity.
  • CAF is calculated using a table.

Object Points

  • Uses a similar process to function points and feature points.
  • Suits object-oriented software.
  • Uses different weighting factors and tables.

[1] Prof. Shervin Shirmohammadi, University of Ottawa SEG4100 Course Notes, Lecture 5

Avatar of admin

by admin

Work Breakdown Structure

September 30, 2007 in Software Project Management

Work Breakdown Structure [1]

  • A hierarchical list of work activities needed to complete the project; a description of the work to be performed broken down to its key components, down to the lowest level.
  • Divide and conquer level
  • Work breakdown structure identifies activities at a level useful for selecting the team with the proper skills.
  • Based on staff number and estimates for the work breakdown structure, schedule cost and duration can be estimated.

Work Breakdown Structure Architecture [1]

  • The work breakdown structure must cover all activities
  • it is crucial to capture all disciplines or stages (requirements, design, implementation, testing…)
  • Project manager must ensure everything is covered

Work Breakdown Structure Ganularity [1]

  • Avoid too much detail and granularity.
  • Don’t plan in more detail than you can manage
  • Project manager has to train and trust the engineering team for those.
  • Stop at a level where there is sufficient information for the people who will work on the activity.
  • Obviously, don’t be too general either!

Milestones [1]

  • A milestone is a significant event
  • Usually associated with an interim deliverable
  • For IIP, there can be a milestone at the end of each iteration.
  • For eXtreme Programming (XP), there is typically a milestone every 1 to 3 weeks.
  • Important to get the numbers right:
    • Too few: big-bang effect, progress will be hard to track
    • Too many: slows down project
  • It is achieved as the result of the completion of a number of activities.

Work Packages [1]

  • Lowest identifiable activities to be completed
  • Contains:
    • Description of work
    • Staffing requirement (who, how many)
    • Name(s) of personnel responsible for completion
    • Schedule
    • Budget ($, hours, …)
    • Acceptance criteria (quality)
  • Used mostly for large groups, or smaller groups of people who haven’t worked with each other before; rarely used in smaller organizations.

Activities and Tasks [1]

  • Activity: the smallest component of the work breakdown structure, usually contains many tasks.
  • Task: the lowest level of effort, typically achievable by one individual.
  • Initially, an educared guess from past experience can be sufficient for the size of an activity. As requirements evolve, this size is estimated better.
  • We cannot have all the details needed for a project plan at the beginning!
  • It might be necessary later to break down larger activities
  • IEEE 1074 provides a set of 65 activities carried out by software project activities (not all of which are needed for all projects, but still a good guidelines)

3 Level Work Breakdown Structure [1]

One possible way to tackle the work breakdown structure:

  • Level 1: workflows
    • Management, environment, requirements, design, …
  • Level 2: phases
    • Inception, elaboration, construction, transition
  • Level 3: activities
    • Lowest level that may be a work package or lead to a number of work packages

Creating the Work Breakdown Structure [1]

  • Go through existing documents
    • requirements
    • design documents
    • customer conversations
  • Synchronize the work breakdown structure with the process framework: keep in mind the life cycle when doing the work breakdown structure.
  • Project manager: sanity check the work breakdown structure:
    • everything is covered
    • granularity is appropriate

[1] Prof. Shervin Shirmohammadi, University of Ottawa SEG4100 Course Notes, Lecture 4

Avatar of admin

by admin

Phases, Requirements and Project Charter

September 30, 2007 in Software Project Management

Project Phases [1]

  • Inception: Establish the project’s scope and boundary, find the critical use cases, exhibit a candidate architecture, estimate the overall cost and schedule for the whole project, with details for the elaboration phase, and estimate risks.
  • Elaboration: Define and validate the architecture, baseline a detailed plan for the construction phase
  • Construction: Achieve useful versions (alpha, beta…), achieve adequate quality.
  • Transition: Achieve final product baseline, achieve stakeholder concurrence of completeness

Project Disciplines [1]

Process Disciplines

  • Business Modeling
  • Requirements
  • Analysis & Design
  • Implementation
  • Testing
  • Deployment

Support Disciplines

  • Configuration Management
  • Change Management
  • Project Management
  • Environment

Architecture [1]

  • The set of views, for the architecturally-significant components, of requirements, analysis, design, implementation, testing, and deployment.
  • Similar to a blue print

Requirements Gathering [1]

  • Gather all stakeholders
    • an individual or group of individuals with a common interest in the software
    • there may be conflicting interests among stakeholders!
    • can be customers, consumers, owners, partners, funders,subcontractors, internals, society, etc…
  • Achieve sufficient requirements
    • Avoid designs details
    • Avoid implementation details
    • Cover only the functions that the software must provide
    • At this stage, don’t be concerned with how the functions are provided
  • Use notations to capture requirements (ex: UML)
    • Don’t just talk about the software, but capture things on paper

<insert info on UML, show user case diagrams>

Use Case Scenarios [1]

  • One or more user scenarios are written down for each use case
    • a lot of ambiguities are resolved at this stage
    • still lots of details remain and are avoided

Ex: Use case: show profile

  1. START: user activates the show profile feature
  2. software asks user to specify profile parameters
  3. software retrieves parameters for database and displays them to the user
  4. FINISH: user cancels the feature

Non-Functional Requirements [1]

  • Captured as part of requirements gathering stage

Ex: (the software should answer queries within 3 seconds)

Requirements Document [1]

  • Includes functional and non-functional requirements
  • Must be signed off by stakeholders

Goal, Objective and Scope [1]

  • Goal: must be defined crisply and clearly
  • Objectives: for a specific target
    • SMART: Specific, Measurable, Achievable, Realistic, Time-Bound.
  • Scope: boundaries of the project: does and does not list
    • not to be confused with features or requirements

Project Charter [1]

  • A document that formally recognizes the existence of a project
  • Provides the project manager with the authority to apply organizational resources to the project: what the project manager can and cannot do.
  • Defines the project goal, scope, and objectives
  • Details the level of quality to be expected
  • Validates the business justification
  • highlights the risk
  • It is the contact: if anything needs resolution, this should specify it
  • when in doubt, read the charter
  • Also specifies the following:
    • what to do if there is a conflict
    • management reconciliation
    • scope change management
    • knowledge transfer
    • training approach
    • anything else…

Sample Charters:

—[1] Prof. Shervin Shirmohammadi, University of Ottawa SEG4100 Course Notes, Lecture 3