Systems Requirements Engineering

1
Systems Requirements Engineering

• Sagar Morabia.
• CS- 577b.

2
Outline.

• Why Requirements Engineering?
• Introduction.
• Steps in Requirements Engineering.
• Summary.
• References.
• Feedback.

3
Why?

• Before a software can be engineered, the system
  in which it resides must be understood systems
  engineering.
• You cant see the forests (system) for the trees
  (technology elements).
• Outcome of the systems engineering process should
  be verified and validated. Hence..

4
Next.

• Why Requirements Engineering?
• Introduction.
• Steps in Requirements Engineering.
• Summary.
• References.
• Feedback.

5
Introduction.

• Outcome of systems engineering process is a
  specification of the system However to assure
  its correctness, we do systems requirements
  engineering.
• Its a mechanism for understanding-
• What customer wants?
• analyzing the need
• assessing the feasibility
• negotiate
• specify the solutions unambiguously
• validating the specifications
• Managing the requirements

6
Next.

• Why Requirements Engineering?
• Introduction.
• Steps in Requirements Engineering.
• Summary.
• References.
• Feedback.

7
Steps in requirements engineering
8
Cont

• Requirement Elicitation Ask the stakeholders
• Problems Scope, understanding, volatility
• Guidelines Assess technical and business
  feasibility, identify the stakeholders, define
  technical environment, identify domain
  constraints, define elicitation methods.
• Requirement analysis and negotiate
• Analyze inter-relatedness, consistency,
  omissions, ambiguity and rank it.

9
Cont

• Requirements Specification
• Types a written document/ a graphical model/ a
  mathematical model/ a prototype/ collection of
  usage scenario/ any of these combinations
• Approach Standard Template v/s usage scenarios.
• This final work product serves as the foundation
  for hardware, software, database and human
  engineering.
• It defines functions and performance, bounds and
  input to and output from the system.

10
Cont

• Requirement Modeling A blueprint or 3-D
  rendering.
• It becomes easy to assess the efficiency of the
  work flow along with satisfying the personal
  requirements which is equally important.
• It helps evaluate the systems components in
  relationship to one another, fit the requirements
  into the picture and also assess the aesthetics
  of the systems as it has been conceived.

11
Cont

• Requirement Validation
• Examines the specification to ensure that all
  system requirements have been stated
  unambiguously, that inconsistencies, omissions,
  errors have been removed and work products
  conform to the standards of the development.
• Primary requirement being technical review,
  technical review team comprising of system
  engineers, customers, users and other stake
  holders who helps in ensuring that the system is
  error free. To do so requirements are examined
  against a set of checklist.

12
Cont

• Requirements Management
• Requirements management is a set of activities
  that help the project team to identify, track and
  control the requirements and changes to them at
  any point in time.
• It is similar to SCM. Each requirement is
  assigned a unique identifier number.
• ltrequirement typegtltrequirement gt
• Requirement type takes value such as F
  Functional, D Data, B Behavioral, I
  interface and P output.
• Traceability matrix (Features, source,
  dependency, subsystem, interface) are developed
  to understand the effects of them on environment
  or other system elements.

13
Next.

• Why Requirements Engineering?
• Introduction.
• Steps in Requirements Engineering.
• Summary
• References
• Feedback

14
Summary

• Requirements engineering would reveal the correct
  requirements, constraints on the system,
  omissions, errors help detecting and correcting
  the errors and help to make sure that the system
  behaves the same way as it was intended to. It
  will also make sure that changes are properly
  accommodated in the system.

15
Next.

• Why Requirements Engineering?
• Introduction.
• Steps in Requirements Engineering.
• Summary.
• References.
• Feedback

16
Reference

• Software Engineering Practitioners approach by
  Roger Pressman.
• Requirements Engineering A good practitioner
  guide Ian sommerville Pete sawyer
• http//cs.wwc.edu/aabyan/435/Requirements.html
• IEEE paper http//ieeexplore.ieee.org/xpl/abs_fr
  ee.jsp?arNumber487319

17
Feedback

• Thank You