Requirement Engineering PDF

Requirements engineering  Requirements Engineering  The requirements for a system are the descriptions of what the system should do  The process of finding out, analyzing, documenting and checking these services and constraints is called Requirements Engineering (R...

Requirements engineering  Requirements Engineering  The requirements for a system are the descriptions of what the system should do  The process of finding out, analyzing, documenting and checking these services and constraints is called Requirements Engineering (RE).  Requirements Engineering  The term ‘requirement’ is not used consistently in the software industry.  In some cases, a requirement is simply a high-level, abstract statement of a service that a system should provide or a constraint on a system.  At the other extreme, it is a detailed, formal definition of a system function.  SRS=User Requirements + System Requirement  User requirements are statements, in a natural language plus diagrams, of what services the system is expected to provide to system users and the constraints under which it must operate.  System requirements are more detailed descriptions of the software system’s functions, services, and operational constraints. The system requirements document (sometimes called a functional specification) should define exactly what is to be implemented. It may be part of the contract between the system buyer and the software developers.  Functional requirements These are statements of services the system should provide, how the system should react to particular inputs, and how the system should behave in particular situations. In some cases, the functional requirements may also explicitly state what the system should not do.  Non-functional requirements These are constraints on the services or functions offered by the system. They include timing constraints, constraints on the devel opment process, and constraints imposed by standards. Non- functional requirements often apply to the system as a whole, rather than individual system features or services. Example of Functional requirements  A user shall be able to search the appointments lists for all clinics.  The system shall generate each day, for each clinic, a list of patients who are expected to attend appointments that day.  Each staff member using the system shall be uniquely identified by his or her eight-digit employee number.  Imprecision in the requirements specification is the cause of many software engineering problems.  In principle, the functional requirements specification of a system should be both complete and consistent.  Completeness means that all services required by the user should be defined.  Consistency means that requirements should not have contradictory definitions.  Non-functional requirements  Non-functional requirements are performance, security, or availability, usually specify or constrain characteristics of the system as a whole. Eg:  reliability, response time, store occupancy, interoperability,safety, and confidentiality  Non-functional requirements are often more critical than individual functional requirements. Types of non-functionalrequirement Eg of non-functional requirements in the MHC-PMS  you should write non-functional requirements quantitatively so that they can be objectively tested  Non-functional requirements often conflict and interact with other functional or non-functional requirements. Metrics for specifying objectively testable non-functional requirements  software requirements document  The software requirements document (sometimes called the software requirements specification or SRS) is an official statement of what the system developers should implement.  SRS=User Requirements + System Requirement  Requirements documents are essential when an outside contractor is developing the software system. Agile Argue Otherwise(let’s talk)  Requirements change so rapidly  Effort is largely wasted  Incrementally write user stories on cards  User prioritizes requirements for implementation in the next increment  Take away  For business systems where requirements are unstable, Agile approach is a good one. Users of a Requirements Document  The level of detail that you should include in a requirements document depends on the type of system that is being developed and the development process used. Eg:  Critical systems = detailed requirements  Outsourcing Development= detailed and precise  inhouse, iterative development= less detailed IEEE Standard for Requirements Documents (IEEE, 1998) Problems with using natural language for requirements specification Requirements specification  Requirements specification is the process of writing down the user and system requirements in a requirements document.  SRS=User Requirements + System Requirement  user requirements  The user requirements for a system should describe the functional and non-functional requirements so that they are understandable by system users who don’t have detailed technical knowledge.  user requirements = functional + non-functional - software jargon  Ideally, the user and system requirements should be clear, unambiguous, easy to understand, complete, and consistent.  you should not use software jargon, structured notations, or formal notations.  You should use natural language, with simple tables, forms, and intuitive diagrams.  System requirements  System requirements are expanded versions of the user requirements that are used by software engineers as the starting point for the system design  System requirements = user requirements + More Details + software jargon  System requirements  They add detail and explain how the user requirements should be provided by the system.  They may be used as part of the contract for the implementation  They should not be concerned with how the system should be designed or implemented. Ways of writing a system requirements specification  User requirements are almost always written in natural language supplemented by appropriate diagrams and tables in the requirements document.  System requirements may also be written in natural language but other notations based on forms, graphical system models, or mathematical system models can also be used.  Graphical models are most useful when you need to show how a state changes or when you need to describe a sequence of actions eg UML  Formal mathematical specifications are sometimes used to describe the requirements for safety- or security-critical systems, but are rarely used in other circumstances.  Natural language specification  Natural language has been used to write requirements for software since the beginning of software engineering.  It is expressive, intuitive, and universal.  It is also potentially vague, ambiguous, and its meaning depends on the background of the reader  To minimize misunderstandings when writing natural language requirement  Invent a standard format(eg 1 requirment : 1 sentence)  Use language consistently (eg ‘shall’ for must have)  Use text highlighting (bold, italic, or color) to pick out key parts of the requirement.  Do not assume that readers understand technical software engineering language(words like ‘architecture’ and ‘module’)  Whenever possible, you should try to associate a rationale with each user requirement(Why The Reuirement). Example requirements for the insulin pump software system  Structured specifications  Structured natural language is a way of writing system requirements where the freedom of the requirements writer is limited and all requirements are written in a standard way.  This approach maintains most of the expressiveness and understandability of natural language but ensures that some uniformity is imposed on the specification.  Structured language notations use templates to specify system requirements. A structured specification of a requirement for an insulin pump  The Robertsons (Robertson and Robertson, 1999) Book recommend  that user requirements be initially written on cards, one requirement per card.  They suggest a number of fields on each card, such as the requirements rationale, the dependencies on other requirements, the source of the requirements, supporting materials  To Use standard form for specifying functional requirements included: 1. A description of the function or entity being specified. 2. A description of its inputs and where these come from. 3. A description of its outputs and where these go to. 4. Information that is needed for the computation or other entities in the system that are used (the ‘requires’ part). 5. A description of the action to be taken. 6. If a functional approach is used, a pre-condition setting out what must be true before the function is called, and a post-condition specifying what is true after the function is called. 7. A description of the side effects (if any) of the operation.  Using structured specifications removes some of the problems of natural language specification.  However, it is still sometimes difficult to write requirements in a clear and unambiguous way, particularly when complex computations  Solution: Tables are particularly useful (see next slide) Tabular specification of computation for an insulin pump  Exercise Scenario: Landmark University Bread Industry Software Development  Landmark University's Bread Industry is looking to modernize its bread production process and supply by developing a software system to manage various aspects of the production, inventory, and sales.  Students are tasked with writing structured specifications for the software system(10 min).  THANKS (More on “Requirements engineering processes........!!!) Q&A