Software Design Lec 2
Software Development process DOES NOT mean programming.
Programming is only one stage of the development process.
Requirements Gathering stages (WHAT)
- What are you solving?
- Who is using the product?
- Talking to people and asking questions.
Design Stage (HOW)
- Software design is the process through which problem specifications are transformed into a plan to build the software.
- This is the stage where choices are made – How are you going to solve the problem.
- Spending time and producing a quality software design speeds up the implementation and leads to better software.
- Checking for errors
- In this stage you test the requirements
- Devise Test cases
Installation and Maintenance Stage
- Boxed production?
- Installed for the client on their system
- Given a task A set of requirements
- What are requirements? A set of operations the software must perform; What the client wants the software to do.
- Only this term?
- Measured in centimeters or inches?
- Registered for the course or physically present?
- Requirements gather is difficult
- Balance competing requirements
- Design can not be created without the requirements.
Examples of requirements
- We need and SQL database
- We need a system to organize inventory
- Run under windows OS
- Must be able to generate daily reports
- Must be able to handle 100 transactions per second
- Must run on our existing computer system
- Make it as cheap as possible.
- We will want demos during development every two weeks
- We need some software to solve our problems
- Must be usable by someone with a grade six education
- Must implement all current legal expectations for this type of system
- Must use the most modern security available
A system analyst was asked to develop a computer system to store different forms in a database. The office that managed the forms was having a lot of trouble keeping track of the different forms. The forms were all similar and were being filed in the wrong places or lost.
- Build the system they want
- Colour the forms so they cannot be mistaken (this was the chosen solution)
- An official statement of the system requirements
- For the clients and users
- For the developers
- Other names: functional specifications; requirements definitions; software requirements specifications
- How should it be written?
The top 10 requirements guidelines:
- Define a standard documents structure
- Readers will become familiar with the format and know how to use it
- Acts as a checklist for the writer so they don’t accidentally omit something
- Software templates can be developed to help format the document
- Make the document easy to change
- Writing, reviewing, and distributing new documents is expensive and time consuming
- If the cost of making changes is too high, then changes may be collected and applied in a batch. This means the document can be out of date while the changes wait to be applied
- Online versions of the documents can lessen the effects of these problems.
- Uniquely identify each requirement
- Give each requirement a unique number
- They can be referenced through the number in the document
- The number can be used to show which requirements have created other requirements.
- Define policies for requirements management
- Explicitly tell people what they are expected to do and why it is done
- Define template for requirements description
- They make the requirement easier to read once the reader understands the format
- They make gathering and writing easier because they provide a checklist of things to include.
- This is similar to a standard document structure but it deals with individual requirements only.
- Use simple language
- Simple language is easier to read and understand
- Be consistent in your description. If you give a name to something, then use the same name all the time
- Short sentences are easier to understand. Use one idea per sentence.
- Organize requirements inspections
- A group of people should meet and systematically check for problems in the requirements document.
- The requirements engineer (system analyst) presents each requirement.
- The group comments about the problems or concerns
- The comments are recorded so the problems can be addressed later
- Define a validation checklist
- This helps the people validating the requirements identify if something is incorrect
- Sample questions included
- Are the requirements complete
- Do you understand what the requirements all mean?
- Are they ambiguous
- Are there any contradictions
- User checklist of requirements problems
- Identify problems which you have experienced in the past and look for them
- Design choices being listed as required
- Combining two requirements into one
- Are there unnecessary requirements
- Is it an ambiguous requirement?
- Plan for conflicts and their solutions
- Requirements – committees
- If requirements are produced by committee then no one is individually responsible for them
- They tend to be excessive and impractical
- The are a whish list instead of a realistic set of objective
- Requirements bloat – it occurs when too many requirements are specified
- Requirements creep – it occurs when the users of developers want to add new requirements which appear to be cleaver or useful
- A few high level objectives must be specified and all later requirements must directly support them.