CS708 - Software Requirement Engineering
Course Page
Q & A
Short Question & Answers
Q1: Who are stakeholders?
  • Software engineers
  • System end-users
  • Managers of system end-users
  • External regulators
  • Domain experts
  • Q2: Input/output of RE Processes?
      RE Process – Inputs:
  • Information: It include the information about the functionality of systems to be replaced and the Information about other systems, which interact with the system being specified
  • Stakeholder needs: Description of what system stakeholders need from the system to support their work
  • Organizational standards: Standards used in an organization regarding system development practice, quality management, etc.
  • Regulations: External regulations such as health and safety regulations, which apply to the system
  • Domain information: General information about the application domain of the system
      RE Process – Outputs:
  • Agreed requirements: A description of the system requirements, which is understandable by stakeholders and which has been agreed by them
  • System specification: This is a more detailed specification of the system, which may be produced in some cases
  • System models: A set of models such as a data-flow model, an object model, a process model, etc., which describes the system from different perspectives
  • Q3: What are the major objective of process improvement?
    Process improvement is concerned with modifying processes in order to meet some improvement objectives Improvement objectives which are; Quality improvement, Schedule reduction, Resource reduction.
    Q4: What are the role of different actors in RE process?
      Actors in the RE Process
  • Requirements engineering involves people who are primarily interested in the problem to be solved (end-users, etc) as well as people interested in the solution (system designers, etc.)
  • Another group of people, such as health & safety regulators, and maintenance engineers may be effected by the existence of the system
  • Role-action diagrams are process models which show the actors associated with different process activities
  • They document the information needs of different people involved in the process
  • They use model of prototype software system as part of requirements elicitation process
  • Q5: Which stakeholder should be part of review team?
      Review Team Membership
  • Reviews should involve a number of stakeholders drawn from different backgrounds. People from different backgrounds bring different skills and knowledge to the review. Stakeholders feel involved in the RE process and develop an understanding of the needs of other stakeholders
  • Review team should always involve at least a domain expert and an end-user
  • Q6: What impact of wrong requirements?
  • When requirements are wrong, systems are late, unreliable and don‟t meet customers needs
  • This results in enormous loss of time, revenue, market share, and trust of customers
  • Q7: What are the change management polices and it stages?
      Change Management Policies
  • The change request process and the information required to process each change request
  • The process used to analyze the impact and costs of change and the associated traceability information
  • The membership of the body which formally considers change requests
  • The software support (if any) for the change control process
      Change Management Stages
  • Problem Analysis and Change Specification: Some requirements problem is identified. This could come from an analysis of the requirements, new customer needs, or operational problems with the system. The requirements are analyzed using problem information and requirements changes are proposed
  • Change Analysis and Costing: This checks how many requirements (and, if necessary, system components) are affected by the change and roughly how much it would cost, in both time and money, to make the change li> Change Implementation: A set of amendments to the requirements document or a new document version is produced. This should, of course, be validated using whatever normal quality checking procedures are used
  • Q8: What are the change in requirements and its sources?
      Changing Requirements
  • All stakeholders want to change requirements, due to different reasons
  • Studies have shown that very significant percentage of delivered defects can be traced back to changing user requirements
  • A major issue in requirements engineering is the rate at which requirements change once the requirement phase has "officially" ended
  • This rate is on average 3% per month in the subsequent design phase, and should go down after that
  • This rate should come down to 1% per month during coding
  • Ideally, this should come down to no changes in testing, however, this is very rare
      Sources of Change
  • New business or market conditions dictate changes in product requirements or business rules
  • New customer needs demand modification of data produced by information systems, functionality delivered by products, or services delivered by computer-based system
  • Reorganization or business growth/downsizing causes changes in project priorities or software engineering team structure
  • Budgetary or scheduling constraints cause a redefinition of the system or product
  • Q9: How many types of error in requirements?
  • Errors of omission: Errors of omission are most common among requirements errors. Domain experts easily forget to convey domain knowledge to requirements engineers, because they consider that to be obvious and implicit
  • Errors of clarity and ambiguity: Second most common errors are those of clarity and ambiguity. Primarily, because natural languages (like English) are used to state requirements, while such languages are themselves ambiguous. For example: object
  • Errors of commission: Errors of commission can also find their way into the requirements documents
  • Errors of speed and capacity: Performance, that is errors of speed and capacity, are also found in requirements. Primarily, these occur due to conflicting understanding or competing needs of different stakeholders
  • Q10: What are the key issues between client organization and requirement team?
  • Financial arrangements
  • Ethical obligations
  • Legal safeguards
  • Personal relationships
  • Denial of information
  • Management of changes
  • Course Instructor

    Dr. Ghulam A Farrukh
    Ph.D Software Engineering
    George Mason University, USA

    Customer Oriented Software Quality Assurance by Frank P. Ginac

    Inroads to Software Quality by Alka Jarvis and Vern Crandell

    Requirements Engineering: Processes and Techniques by Gerald Kotonya and Ian Sommerville

    Software Assessments, Benchmarks, and Best Practices by Capers Jones

    Software Engineering: A Practitioner’s Approach by Roger S. Pressman

    Software Engineering by Ian Sommerville

    Software Engineering Quality Practices by Ronald K. Kandt

    Software Quality: Analysis and Guidelines for Success by Capers Jones

    Software Requirements: Objects, States, and Functions by Alan M. Davis

    High Quality Low Cost Software Inspections by Ronald A. Radice