Lecture 5 defining the system
- 1. Defining the System Lecture # 5 Ms. Shazia Yousaf Lecturer, Department of computer science, University of Sargodha Mandi Bahauddin Campus
- 2. System Specification System engineering is preformed to break complex systems into subsystems System requirements Versus Subsystem requirements The lowest level specification Hardware requirement specification Software requirement specification
- 3. System Specification in case of Product lines system Develop a common document Product family vision document Family common use case model Common software requirements specification document Develop for each product Vision document Use case model document Software requirement specification document
- 4. Document both kinds of requirements Requirements for current releases Requirements for future releases
- 5. Artifacts from Requirement Discipline Input Artifact Vision Artifact Glossary (Party Descriptive) Descriptive Artifact SRS Modeling Artifact Use Cases and use case model
- 6. Purpose of Requirement Artifacts Basis on which customer and user come to agreement on what the system should do Give system developers better understanding of requirements.
- 7. Glossary Artifacts Defines important terminologies (project unfamiliar) Define terms related to different artifacts of the project Should be a unique Glossary for whole project Known as informal data dictionary consisting of data definitions
- 8. The Vision Document “If I were permitted to develop only one document, model or other artifact in support of a software project, a short, well crafted vision document would be my choice” Philippe kruchten
- 9. Vision Document Describes application in general terms including description of Target market System users Application features Defines problem and solution at high level of abstraction (covers both needs and features)
- 10. Contd.. Serves as basis for discussion and agreement between Marketing department Project team Management team It is a concise description of everything you consider to be most important about the product or application.
- 12. Delta Vision Document Delta vision document focuses on what has changed With development of software the vision document evolves. We should keep it concise and to the point (not difficult for first release) In further releases their would be information which has not changed and features which have been already implemented.
- 13. Versioning Release 1.0 Should at least have General and introductory information A description of the users of the system and markets served Features for 1.0 release Other requirements such as environmental Future features that are elicited but not to be released in 1.0 release. Release 2.0 More features obtained from feedback and continuous elicitation process Modified features (features of 1.0 release which did not give the expected value) some features will be deleted known as anti requirements, should record this in vision document.
- 14. Due to versioning as the project proceeds the document grows and becomes difficult to read. For the purpose for comprehensibility the concept of “ Delta Vision Document”. Focuses on what has changed or what is new with some context information What is different about this release We can also remerge all vision documents to get a comprehensible picture thus Delta vision document is “ what really matters” at that specific time.
- 15. Descriptive Artifact: SRS Consists of Functional and non-functional Requirements (supplementary requirements) Official statement of system requirements Functional requirements specify what the system must do, should be testable Non- Functional requirements or supplementary specifications place restrictions on the product and process, place external constraints in the manner system is produced.
- 16. Characteristics of a Well Constructed SRS Correct Complete Consistent Unambiguous Modifiable Traceable Verifiable
- 17. The Champion Questions like Who develops and maintains this all important document? Who manages customer expectations? Who negotiates with the development team, customer, marketing department etc? In almost every project there is a role of a champion person who “ played bigger than life” role. Project champion can have variety of titles e.g. product manager, project manager, marketing manager, IT manager, project lead etc but no matter what he must do the following.
- 18. Responsibilities of Champion Manage the elicitation process and become comfortable when enough requirements are discovered. Manage conflicting inputs of stakeholders Make tradeoffs between features(valuable features to great no. of stakeholders) Own the product vision Advocate for the product Negotiate with management, users and developers Defend against feature creep Maintain a healthy tension between what the customer wants and what developers can give Manage expectations of stakeholders Be representative of the official channel between the customer and the development team Communicate features of release to all Review software specification for conformance to vision Manage changes in features
- 19. Thanks