software engineering unit 2 jntuh r18 syllabus

software engineering unit 2 jntuh r18

1. UNIT - II Software Requirements Functional and non-functional requirements User requirements S ystem requirements Interface Specifications S oftware requirements document. Requirements engineering process Feasibility studies, R equirements elicitation and analysis R equirements validation R equirements management.

2. Software Requirements

3. Software requirements The different types of requirements are Functional Requirements Non Functional Requirements Domain requirements user requirements system requirements

4. SOFTWARE requirements THE SOFTWARE REQUIREMNTS ARE REPRESENTED AS THE BELOW: Functional requirements Statements of services the system should provide, h ow 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.

5. EXAMPLE OF 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.

6. functional requirements FOR LIBSYS 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.

7. 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. Non-functional requirements may be more critical than functional requirements. If these are not met, the system is useless.

8. 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.

9. Non-functional requirement types

10. Non-functional requirements for lib sys 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 defined in XYZCo-SP-STAN-95. 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.

11. Domain requirements Derived from the application domain and describe system characteristics and features that reflect the domain. Domain requirements be functional requirements, constraints on existing requirements or define specific computations. If domain requirements are not satisfied, the system may be unworkable. Examples of Domain requirements train operation, medical records, e-commerce etc that reflect the environment in which the system operates

12. User requirements They should only specify the external behavior of the system and should avoid, as far as possible, system design characteristics. Should describe functional requirements in such a way that they are understandable by system users who don’t have detailed technical knowledge. Consequently, if you are writing user requirements, you should not use software jargon, structured notations or formal notations, or describe the requirement by describing the system implementation. You should write user requirements in simple natural language, with simple tables and forms and intuitive diagrams

13. USER REQUIREMENT EXAMPLE FOR LIBSYS requirement 4..5 LIBSYS shall provide a financial accounting system that maintains records of all payments made by users of the system. System managers may configure this system so that regular users may receive discounted rates.

14. Problems with natural language however, various problems can arise when requirements are written in natural language sentences in a text document: Lack of clarity ACCURACY SHOULD BE MAINTAINED WHILE making the document . Requirements confusion Functional and non-functional requirements tend NOT BE to be mixed-up. Requirements amalgamation Several different requirements may be expressed together.

15. Guidelines for writing requirements Invent a standard format (template) and use it for all requirements. Use language consistently. You should always distinguish between mandatory and desirable requirements. Use text highlighting (bold, italic or colour ) to pick out key parts of the requirement. Avoid, as far as possible, the use of computer jargon

16. System requirements More detailed specifications of system functions, services and constraints than user requirements. They are intended to be a basis for designing the system. It should define exactly what is to be implemented. It may be part of the contract between the system buyer and the software developers.

17. Problems with NL specification Ambiguity The readers and writers of the requirement must interpret the same words in the same way. NL is naturally ambiguous so this is very difficult. Over-flexibility The same thing may be said in a number of different ways in the specification. Lack of modularisation NL structures are inadequate to structure system requirements.

18. Alternatives to NL specification

19. INTERFACE SPECIFICATIONS Interface specification, in the context of software development and computer systems, refers to a detailed description or set of rules that define how different software components or modules should interact with each other. It acts as a contract or agreement that ensures seamless communication and integration between various parts of a software system. In simpler terms, an interface specification outlines the rules and guidelines for how different parts of a software application should "talk" to each other, exchange data, and cooperate to perform specific tasks. These interfaces can be between software modules, software and hardware components, or even between different software systems. Key Points about Interface Specification: Standardization:  Interface specifications standardize the communication between components, making it easier for developers to understand how to interact with other parts of the system. Abstraction:  Interfaces hide the implementation details of a component, allowing other parts of the system to interact with it without needing to know the internal complexities. Encapsulation:  Interface specifications help enforce encapsulation, separating the concerns of different components and promoting modular design. Flexibility:  By defining clear interfaces, components can be easily replaced or upgraded without affecting other parts of the system, as long as they adhere to the same interface specification. Interoperability:  Interface specifications facilitate interoperability, enabling components from different vendors or systems to work together seamlessly.

20. 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

21. Users of a requirements document

22. 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.

23. Requirements document structure FOR LARGE PROJECTS Preface Introduction Glossary User requirements definition System architecture System requirements specification System models System evolution Appendices Index

24. Requirements Engineering Process

25. Requirements Engineering Processes The goal of requirement engineering process is to create and maintain a system requirements document. The overall process include four level process.

26. Requirements engineering process

27. Requirements engineering process (1) Feasibility Study: These are concerned with assessing whether the system is useful to the business or not. It produces Feasibility Report. (2)Requirement Elication and Analysis: It discovers requirements and produces system models. (3)Requirements Specification : Converting these requirements in to standard format. (4) Requirement Validation: checking that the requirements actually define the system that customer wants . It produces SRS document.

28. Requirements engineering process Ion Sommerville found an alternative perspective ,with 3 stage activities. All these 3 activities are organized as an iterative process around a spiral . The following Spiral diagram shows how the requirements are developed in different levels in detail.

29. Topics covered Feasibility studies Requirements elicitation and analysis Requirements validation REQUIREMENTS MANAGEMENT

30. Feasibility studies A feasibility study decides whether or not the proposed system is worthwhile. The study checks if the system contributes to organizational 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 It helps us to start a business, purchase of an existing system,or an expansion of system required.

31. Feasibility study involves in 3 steps: (a) Information Assessment : It has 3 types (1) Economic Feasibility – cost of equipments,budget (2) Operational Feasibility – Easy to use or any training (3) Technical Feasibility.- discuss about H/w aNd s/w req Feasibility studies

32. Feasibility studies(Cont..) (b ) Information Collection : The software engineering organization discover answers for the following sample questions What are the problems with current processes and how would a new system help alleviate these problems? What direct contribution will the system make to the business objectives and requirements Does the system require technology that has not previously been used in the organisation?

33. Feasibility studies(cont..) (3) Report writing: Based on these questions, the report is developed .The organization will take decision whether to continue the project or cancel the project Normally Feasibility study will take 2 or 3 weeks.

34. Topics covered Feasibility studies Requirements elicitation and analysis Requirements validation Requirements management

35. Requirement elicitation and analysis Involves technical staff with customers to find out about the application domain , the services that the system should provide and the system’s operational constraints Involves many stakeholders , such as end-users, managers, engineers, domain experts, trade unions, etc.

36. Banking ATM system – An example Services include cash and check deposit, cash withdrawal, message passing , ordering a statement and transferring funds

37. Banking ATM system – An example For example, system stakeholders for a bank ATM include: I. Current bank customers who receive services from the system 2. Representatives from other banks who have reciprocal agreements that allow each other's ATMs to be used 3. Managers of bank branches 4. Counter staff at bank branches who are involved in the day-to-day running of the system 5. Database administrators who are responsible for integrating the system with the bank's customer database

38. Banking ATM system – An example 6. Bank security managers who must ensure that the system will not pose a security hazard 7. The bank's marketing department who are likely be interested in using the system as a means of marketing the bank 8. Hardware and software maintenance engineers who are responsible for maintaining and upgrading the hardware and software 9. National banking regulators who are responsible for ensuring that the system conforms to banking regulations

39. Problems of requirements analysis Stakeholders don’t know what they really want Stakeholders express requirements in their own terms Different stakeholders may have conflicting requirements Organizational and political factors may influence the system requirements The requirements change during the analysis process, because new stakeholders may emerge and the business environment may change

40. The requirements analysis process

41. The process activities are: 1. Requirements discovery This is the process of interacting with stakeholders in the system to collect their requirements. It uses different types of techniques like Viewpoints, Scenarios, Interviewing, Use cases, Ethanography and documentation are also discovered during this activity. 2. Requirements classification and organisation This activity takes the unstructured collection of requirements, groups related requirements and organizes them into coherent clusters. The requirements analysis process

42. 3. Requirements prioritization and negotiation Inevitably, where multiple stakeholders are involved, requirements will conflict. This activity is concerned with finding and resolving requirements conflicts through negotiation. 4. Requirements documentation The requirements are documented and input into the next round of the spiral. Formal or informal requirements documents may be produced. The requirements analysis process

43. Techniques for requirements elicitation and analysis Viewpoint-oriented elicitation Scenarios Ethnography Interviewing Use cases

44. Viewpoint-oriented elicitation Stakeholders represent different ways of looking at a problem or problem viewpoints There are 3 different types of view points. a) Interactive Viewpoints b) Indirect viewpoints c) Domain Viewpoints

45. Example of LIB SYS Viewpoint

46. Interviewing Interviews may be of two types: 1. Closed interviews where the stakeholder answers a predefined set of questions. 2. Open interviews where there is no predefined agenda. The requirements engineering team explores a range of issues with system stakeholders and hence develops a better understanding of their needs.

47. Scenarios Scenarios are descriptions of how a system is used in real time(the interaction) They are helpful in requirements elicitation as people can relate to these more readily than abstract statement of what they require from a system Scenarios are particularly useful for adding detail to an outline requirements description

48. Scenario descriptions Including System state description at the beginning of the scenario Normal flow of events in the scenario What can go wrong and how this is handled Other concurrent activities System state on completion of the scenario

49. Event scenario - start transaction

50. Use cases Use-cases are a scenario based technique in the UML which identify the actors in an interaction and which describe the interaction itself A set of use cases should describe all possible interactions with the system Sequence diagrams may be used to add detail to use-cases by showing the sequence of event processing in the system

51. Library use-cases

52. Ethnography A social scientists spends a considerable time observing and analysing how people actually work People do not have to explain or articulate their work Social and organizational factors of importance may be observed Requirements that are derived from cooperation and awareness of other people’s activities

53. Topics covered Feasibility studies Requirements elicitation and analysis Requirements validation Requirement management

54. Requirements validation Requirements validation is concerned with showing that the requirements actually define the system that the customer wants. Requirements validation is important because errors in a requirements document can rework costs when they are discovered during development or after the system is in service. During the requirements validation process, checks should be carried out on the requirements in the requirements document.

55. Requirements validation These checks include: Validity checks Consistency checks Completeness checks Realism checks Verifiability

56. 1. Validity checks A user may think that a system is needed to perform certain functions which are mostly given by stakeholders with distinct needs so we have to keep validity checks wherever needed at every stage. 2. Consistency checks Requirements in the document should not conflict and will not change never . There we have to keep Consistency checks . Example : Login ,Registration pages. 3. Completeness checks The requirements document should include all functions, and constraints intended by the system user. Requirements validation

57. 4. Realism checks :T he requirements should be checked to ensure that they could actually be implemented by existing technology , These checks should also take account of the budget and schedule for the system development 5. Verifiability To reduce the dispute between customer and contractor, system requirements should always be written so that they are verifiable. This means that you should be able to write a set of tests that can demonstrate that the delivered system meets each specified requirement.

58. Requirements validation techniques Requirements reviews Systematic manual analysis of the requirements Prototyping Using an executable model of the system to check requirements. Test-case generation Developing tests for requirements to check testability

59. Requirements Management The requirements for large software systems are always changing, It is hard for users and system customers to anticipate what effects the new system will have on the organization. Once end-users have experience of a system, they discover new needs and priorities Requirements management is the process of understanding and controlling changes to system requirements

60. Requirements fall into two classes: 1. Enduring requirements These are relatively stable requirements that derive from the core activity of the organization and which relate directly to the domain of the system. For example, in a hospital, there will always be requirements concerned with patients, doctors, nurses and treatments. 2. Volatile requirements These are requirements that are likely to change during the system development process or after the system has been become operational. An example would be requirements resulting from government healthcare policies.

61. Requirements Management Planning Planning is an essential first stage in the requirements management process. For each project, the planning stage establishes the level of requirements management detail that is required. During the requirements management stage, you have to decide on: Requirements identification Each requirement must be uniquely identified so that it can be cross-referenced by other requirements and so that it may be used in traceability assessments. A change management process This is the set of activities that assess the impact and cost of changes. . 3. Traceability policies These policies define the relationships between requirements, and system design that should be recorded and how these records should be maintained. 4. CASE tool support Requirements management involves the processing of large amounts of information. Tools that may be used range from specialist requirements management systems to spreadsheets and simple database systems.

62. (1 ) Requirements identification : Each requirement must be uniquely identified so that it can be cross-referenced by other requirements and so that it may be used in traceability assessments. (2) Requirement Change Management 1. Problem analysis and change specification During this stage, the problem or the change proposal is analyzed to check that it is valid. 2. Change analysis and costing The effect of the proposed change is assessed using traceability information and general knowledge of the system requirements. The cost of making the change is estimated and Once this analysis is completed, a decision is made whether to proceed with the requirements change.. 3. Change implementation The requirements document and, where necessary, the system design and implementation are modified. Individual sections can be changed and replaced without affecting other parts of the document.

63. There are three types of traceability information that may be maintained: 1. Source traceability information links the requirements to the stakeholders who proposed the requirements ,When a change is proposed, you use this information to find and consult the stakeholders about the change 2. Requirements traceability information links dependent requirements within the requirements document. You use this information to assess how many requirements are likely to be affected by a proposed change and the extent of consequential requirements changes that may be necessary. 3. Design traceability information links the requirements to the design modules where these requirements are implemented. (3) Traceability policies

64. Figure 7.12 shows a simple traceability matrix that records the dependencies between requirements. A 'D' in the row/column intersection illustrates that the requirement in the row depends on the requirement named in the column; an 'R' means that there is some other, weaker relationship between the requirements.

65. Requirements management needs automated support; the CASE tools for this should be chosen during the planning phase. You need tool support for: l. Requirements storage The requirements should be maintained in a secure, managed data store that is accessible to everyone involved in the requirements engineering process. 2. Change management The process of change management is simplified if active tool support is available. 3. Traceability management : Some tools use natural language processing techniques to help you discover possible relationships between the requirements.. (4) CASE tool support