1. K. Ingram (with thanks to A. Seddon) Staffordshire UNIVERSITY School of Computing Introduction to Software System Design

2. K. Ingram (with thanks to A. Seddon) Staffordshire UNIVERSITY School of Computing Information systems design l Software is an example of an artifact. An artifact is: a product of human art & workmanship (Oxford dictionary) l Artifacts need to be: – designed (in order to meet some specific need) – fabricated (according to the plans created by the design)

3. K. Ingram (with thanks to A. Seddon) Staffordshire UNIVERSITY School of Computing The Waterfall Approach 1. Requirements Analysis 2. Solution Design 3. Software Creation 4. Software Testing 5. System Hand-over 6. Maintainance

4. K. Ingram (with thanks to A. Seddon) Staffordshire UNIVERSITY School of Computing Requirements Analysis Requirements Analysis is primarily concerned with what the end user wants Need knowledge of l the problem domain l the solution space (often part of feasibility study)

5. K. Ingram (with thanks to A. Seddon) Staffordshire UNIVERSITY School of Computing Systems Analysis This task specifies what the chosen solution should do Two forms of requirement emerge from this: l functional requirements l non-functional requirements

6. K. Ingram (with thanks to A. Seddon) Staffordshire UNIVERSITY School of Computing Software Design Design is concerned with how the requirement is to be met by the eventual system The designer’s task is to solve the problems posed by requirements elicitation and systems analysis

7. K. Ingram (with thanks to A. Seddon) Staffordshire UNIVERSITY School of Computing A major difficulty The fundamental problem is that designers are obliged to use current information to predict a future state that will not come about unless their predictions are correct. The final outcome of designing has to be assumed before the means of achieving it can be explored: designers have to work backwards in time from an assumed effect upon the world to the beginning of a chain of events that will bring the effect about ( J C Jones, Design Methods: Seeds of Human Futures, 1970)

8. K. Ingram (with thanks to A. Seddon) Staffordshire UNIVERSITY School of Computing The design process l Purpose: to produce a plan which can be used as a blueprint for the implementation, which describes: –system structure (how elements are related ) –how elements fit together l For software design an added difficulty is the use of static forms to model dynamic properties of our solution

9. K. Ingram (with thanks to A. Seddon) Staffordshire UNIVERSITY School of Computing The design plan should... l describe the process aspects of the design l describe the product aspects of the design Software is distinguished from artifacts such as bridges, clocks etc because of this dual nature of design.

10. K. Ingram (with thanks to A. Seddon) Staffordshire UNIVERSITY School of Computing How designers work domain knowledge

11. K. Ingram (with thanks to A. Seddon) Staffordshire UNIVERSITY School of Computing How designers work l Experienced designers working in familiar domains will make extensive use of experience ( reuse of domain knowledge) l Work in an opportunistic manner, adapting strategy to problem and evolving solution l If no domain knowledge then use of a design method ( method knowledge ) is the substitute

12. K. Ingram (with thanks to A. Seddon) Staffordshire UNIVERSITY School of Computing Aspects of Software Design Information Structure Interfaces Processes Controls Security

13. K. Ingram (with thanks to A. Seddon) Staffordshire UNIVERSITY School of Computing Processes l What the software must do l Use the Data Flow Diagram processes as a basis l Create “mini-specifications” for each action required by the system l Event-driven systems: need a mini-spec for the response to each event

14. K. Ingram (with thanks to A. Seddon) Staffordshire UNIVERSITY School of Computing Information Structure l How is the information to be stored? l Use Logical Data Structure as the basis l Example: –Logical Data = “customer information”, –Physical Data = Customer contact table, Customer Purchasing History, Customer Query History. l Use Normalisation for database design

15. K. Ingram (with thanks to A. Seddon) Staffordshire UNIVERSITY School of Computing Interfaces l How will the inputs and outputs look? l Create “sketches” of screen layouts and printouts. l Identify “action points” to link to your process design e.g. command buttons, combo boxes l Consider the “look and feel”

16. K. Ingram (with thanks to A. Seddon) Staffordshire UNIVERSITY School of Computing Controls l How does the user know the system is running correctly l Examples: –Can get summary statistics –Cannot accidentally repeat procedures

17. K. Ingram (with thanks to A. Seddon) Staffordshire UNIVERSITY School of Computing Security l Keeping the system safe from interference, keeping it up and running.

18. K. Ingram (with thanks to A. Seddon) Staffordshire UNIVERSITY School of Computing Privacy l Keeping information in the system private – not for unauthorised eyes.

19. K. Ingram (with thanks to A. Seddon) Staffordshire UNIVERSITY School of Computing V & V l Verification Are we building the system right? l Validation Are we building the right system?

20. K. Ingram (with thanks to A. Seddon) Staffordshire UNIVERSITY School of Computing V & V - some difficulties l Expressing requirements in terms that allow them to be related to the design model l User requirements are likely to change during development l Requirements describe a process and this is difficult to describe analytically

21. K. Ingram (with thanks to A. Seddon) Staffordshire UNIVERSITY School of Computing Design Guidelines l Many software development methodologies include the design stage

22. K. Ingram (with thanks to A. Seddon) Staffordshire UNIVERSITY School of Computing Design as problem solving l Key factor is the use of abstraction to: –help model solution of essential aspects; –separate logical and physical aspects –help make decisions about choices l The ultimate criteria should be that of fitness of purpose