• Like
Un it 2-se-mod-staff
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Un it 2-se-mod-staff




Published in Education , Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads


Total Views
On SlideShare
From Embeds
Number of Embeds



Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

    No notes for slide


  • 1. UNIT-2 Software Requirements
  • 2. Requirements engineering • The process of establishing the services that the customer requires from a system and the constraints under which it operates and is developed. • The requirements themselves are the descriptions of the system services and constraints that are generated during the requirements engineering process.
  • 3. What is a requirement? • It may range from a high-level abstract statement of a service or of a system constraint to a detailed mathematical functional specification. • This is inevitable as requirements may serve a dual function – May be the basis for a offer for a contract - therefore must be open to interpretation(explanation); – May be the basis for the contract itself - therefore must be defined in detail; – Both these statements may be called requirements.
  • 4. 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.
  • 5. Definitions and specifications System req specification: Extenal file+have a ass tool+it display spec icon for user +provide facility for icon it represent external file type User req Definitions: representing and access EXT files created by other tools
  • 6. Requirements readers
  • 7. 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. • Non-functional requirements – constraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc. • Domain requirements – Requirements that come from the application domain of the system and that reflect characteristics of that domain.
  • 8. 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 but functional system requirements should describe the system services in detail.
  • 9. The LIBSYS system • A library system that provides a single interface to a number of databases of articles in different libraries. • Users can search for, download and print these articles for personal study.
  • 10. Examples of functional requirements • The user shall be able to search either all of the initial set of databases or select a subset from it. • The system shall provide appropriate viewers for the user to read documents in the document store. • Every order shall be allocated a unique identifier (ORDER_ID) which the user shall be able to copy to the account’s permanent storage area.
  • 11. Requirements imprecision(problem) • Problems arise when requirements are not precisely stated. • Ambiguous requirements may be interpreted in different ways by developers and users. • Consider the term ‘appropriate viewers’ – User intention - special purpose viewer for each different document type; – Developer interpretation - Provide a text viewer that shows the contents of the document.
  • 12. Requirements completeness and consistency • In principle, requirements should be both complete and consistent. • Complete – They should include descriptions of all facilities required. • Consistent – There should be no conflicts or contradiction in the descriptions of the system facilities. .
  • 13. Non-functional requirements • These define system properties and constraints e.g. reliability, response time and storage requirements. Constraints are I/O device capability, system representations, etc. • Process requirements may also be specified mandating a particular CASE system, programming language or development method. • Non-functional requirements may be more critical than functional requirements. If these are not met, the system is useless.
  • 14. Non-functional 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.
  • 15. Non-functional requirement types Perfor mance requir ements Space requir ements Usa bility requir ements Efficiency requir ements Relia bility requir ements Porta bility requir ements Inter oper a bility requir ements Ethical requir ements Leg isla tive requir ements Implementa tion requir ements Standar ds requir ements Deli very requir ements Safety requir ements Pri vacy requir ements Product requir ements Organisational requir ements External requir ements Non-functional requir ements
  • 16. Non-functional requirements examples • Product requirement The user interface for LIBSYS shall be implemented as simple HTML without frames or Java applets. • Organisational requirement The system development process and deliverable documents shall conform to the process and deliverables. • External requirement The system shall not disclose any personal information about customers apart from their name and reference number to the operators of the system.
  • 17. The requirements document • The 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
  • 18. Users of a requirements document
  • 19. Requirements document structure • Preface • Introduction • Glossary • User requirements definition • System architecture • System requirements specification • System models • System evolution • Appendices • Index
  • 20. IEEE requirements standard • Defines a generic structure for a requirements document that must be instantiated for each specific system. – Introduction. – General description. – Specific requirements. – Appendices. – Index.
  • 21. 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 – Feasibility studies – Requirements elicitation; – Requirements analysis; – Requirements validation; – Requirements management.
  • 22. The requirements engineering process
  • 23. Requirements engineering Requirements specification Requirements validation Requirements elicitation System requirements specification and modeling System requirements elicitation User requirements specification User requirements elicitation Business requirements specification Prototyping Feasibility study Reviews Syst em requirements document
  • 24. Feasibility studies[possible analysis] • A feasibility study decides whether or not the proposed system is worthwhile. • A short focused study that checks – If the system contributes to organisational objectives; – If the system can be engineered using current technology and within budget; – If the system can be integrated with other systems that are used.
  • 25. Feasibility study implementation • Based on information assessment (what is required), information collection and report writing. • Questions for people in the organisation – What if the system wasn’t implemented? – What are current process problems? – How will the proposed system help? – What will be the integration problems? – Is new technology needed? What skills? – What facilities must be supported by the proposed system?
  • 26. Software prototyping • A prototype is an initial version of a system used to demonstrate concepts and try out design options. • A prototype can be used in: – The requirements engineering process to help with requirements elicitation and validation; – In design processes to explore options and develop a UI design; – In the testing process to run back-to-back tests.
  • 27. Prototyping • For some large systems, incremental iterative development and delivery may be impractical; this is especially true when multiple teams are working on different sites. • Prototyping, where an experimental system is developed as a basis for formulating the requirements may be used. This system is thrown away when the system specification has been agreed.
  • 28. Benefits of prototyping • Improved system usability. • A closer match to users’ real needs. • Improved design quality. • Improved maintainability. • Reduced development effort.
  • 29. Back to back testing
  • 30. The prototyping process
  • 31. Throw-away prototypes • Prototypes should be discarded after development as they are not a good basis for a production system: – It may be impossible to tune the system to meet non-functional requirements; – Prototypes are normally undocumented; – The prototype structure is usually degraded through rapid change; – The prototype probably will not meet normal organisational quality standards.
  • 32. TCS2411 Software Engineering 32 Functional Modeling • In understanding the requirements of the software, the functions required by the customer will be identified • All the functions process information in some way in the system • Basically input process output • Representation of how information is transformed
  • 33. Data-processing models • Data flow diagrams (DFDs) may be used to model the system’s data processing. • These show the processing steps as data flows through a system. • DFDs are an intrinsic part of many analysis methods. • Simple and intuitive notation that customers can understand. • Show end-to-end processing of data.
  • 34. Order processing DFD
  • 35. Data flow diagrams • DFDs model the system from a functional perspective. • Tracking and documenting how the data associated with a process is helpful to develop an overall understanding of the system. • Data flow diagrams may also be used in showing the data exchange between a system and other systems in its environment.
  • 36. Insulin pump DFD
  • 37. Behavioural models • Behavioural models are used to describe the overall behaviour of a system. • Two types of behavioural model are: – Data processing models that show how data is processed as it moves through the system; – State machine models that show the systems response to events. • These models show different perspectives so both of them are required to describe the system’s behaviour.
  • 38. State machine models • These model the behaviour of the system in response to external and internal events. • They show the system’s responses to stimuli so are often used for modelling real-time systems. • State machine models show system states as nodes and events as arcs between these nodes. When an event occurs, the system moves from one state to another. • Statecharts are an integral part of the UML and are used to represent state machine models.
  • 39. Statecharts • Allow the decomposition of a model into sub- models (see following slide). • A brief description of the actions is included following the ‘do’ in each state. • Can be complemented by tables describing the states and the stimuli.
  • 40. Microwave oven state description Stat e Description W aiting The o ven is wa iting for input. The display shows the currentt ime. Half p ower The o ven pow er is set to 300 w atts. The d is play shows ŌHalf p owerÕ. Full power The o ven pow er is set to 600 w atts. The d is play shows ŌFull powerÕ. Set time The cooking time is s et to the userÕs input value. The display shows the cooking time select ed and is updated as the t im e is s et. Disabled Oven operation is dis abled for safety. Interior oven light is on. Dis play shows ŌNot readyÕ. Enabled Oven o peration is enabled. Interior oven light is off. Display s how s ŌReady to cookÕ. Operation Oven in operation. Interior oven light is on. Display shows the tim er countdow n. On com pletion of cooking, the buzz er is sounded for 5 s econds. Oven light is on. Dis play shows ŌCooking com pleteÕ while buzze r is sounding.
  • 41. Microwave oven stimuli Stim ulus Description Half p ow er The u ser has pr essed the half pow er button Full power The u ser has pr essed the full pow er button Time r The u ser has pr essed one of the tim er buttons Numb er The u ser has pr essed a numeric ke y Door open The o ven door sw itch is n ot closed Door closed The o ven door sw itch is closed Start The u ser has pr essed the start button Cance l The u ser has pr essed the ca ncel button
  • 42. Microwave oven operation
  • 43. Semantic data models • Used to describe the logical structure of data processed by the system. • An entity-relation-attribute model sets out the entities in the system, the relationships between these entities and the entity attributes • Widely used in database design. Can readily be implemented using relational databases. • No specific notation provided in the UML but objects and associations can be used.
  • 44. Library semantic model
  • 45. Structured methods(analysis) • Structured methods incorporate system modelling as an inherent part of the method. • Methods define a set of models, a process for deriving these models and rules and guidelines that should apply to the models. • CASE tools support system modelling as part of a structured method.
  • 46. Method weaknesses • They do not model non-functional system requirements. • They do not usually include information about whether a method is appropriate for a given problem. • The may produce too much documentation. • The system models are sometimes too detailed and difficult for users to understand.
  • 47. CASE workbenches • A coherent set of tools that is designed to support related software process activities such as analysis, design or testing. • Analysis and design workbenches support system modelling during both requirements engineering and system design. • These workbenches may support a specific design method or may provide support for a creating several different types of system model.
  • 48. An analysis and design workbench Centr al infor ma tion repository Code gener ator Query langua ge facilities Structur ed dia g ramming tools Da ta dictionary Repor t gener a tion facilities Design, anal ysis and checking tools For ms cr ea tion tools Impor t/e xpor t facilities
  • 49. Analysis workbench components • Diagram editors • Model analysis and checking tools • Repository and associated query language • Data dictionary • Report definition and generation tools • Forms definition tools • Import/export translators • Code generation tools
  • 50. Data dictionaries • Data dictionaries are lists of all of the names used in the system models. Descriptions of the entities, relationships and attributes are also included. • Advantages – Support name management and avoid duplication; – Store of organisational knowledge linking analysis, design and implementation; • Many CASE workbenches support data dictionaries.
  • 51. Data dictionary entries Name Description Typ e Date Artic le Deta ils of the published article that may be ord ered by people using LI BSYS . Entity 30.12.2002 authors The nam es of the authors of the artic le who may be due a share of the f ee. Attribute 30.12.2002 Buyer The person or org anis ation that orders a co py of the article . Entity 30.12.2002 fee- paya ble -to A 1:1 relationship between Artic le and the Copyrig ht Agency w ho should b e paid the copyright fee. Rela tio n 29.12.2002 Address (Buyer) The address of the buyer. Th is is used to any paper billing inform ation t hat is required. Attribute 31.12.2002