Reference and guide to SFIA version 7. Framework status: Requirements.

#8 REQM - Improvements to address needs of Software Engineering: change request pending

Some changes in emphasis and wording across the Skill description and skill level descriptions to ensure Software Engineering is addressed.

Areas to review:

  1. Focus on requirements in general - not an over emphasis on  business solution requirements
  2. Scope management should be part of Project management.
  3. Ensure reference to requirements elicitation, documentation and change management.
  4. Consider best way to address engineering skills related to verification and validation - is it standalone or part of each engineering skill?


This change request is one of a number which are proposing revisions to SFIA to ensure it fully supports Software Engineering while retaining overall industry wide applicability and integrity.

The updates will support:

  • The Software Engineering & Technology industry, it's employers and professionals to close skill gaps, attract and retain talent and improve the performance and productivity of engineers
  • Alignment of Software Engineering training / accreditation
  • Professional development through the IEEE-CS and other professional bodies representing software engineers
  • Universities, technical institutes, and other higher education organisations to support professional education and accreditation and enhance the employability of their students

Skill requirements for Software Engineering have been cross checked against the Software Engineering Body of Knowledge  (SWEBOK) Chapter 1: Software Requirements

Also need to consider the relationship (e.g. unique skills and overlapping skills) between Software Engineering and IT.

Attached to Requirements definition and management


Steve Dusting says:
Aug 23, 2017 04:59 AM

PRMG manages the scope of a project, but REQM defines the scope after consultation with stakeholders. REQM sets the boundaries within which PRMG can manage the scope. Changes in scope identified during a project will need to be further analysed as to the impact on the organisation and base-line requirements.

Julian Bass says:
Sep 17, 2017 08:44 PM

Good to update this to reflect recent developments in agile requirements gathering, user stories and so on. Need to be careful distinguish support for old-fashioned big design up-front in those sectors where that is necessary (such as saflety-critical) while supporting agile approaches for business information systems.

Ian Seward says:
Oct 03, 2017 07:55 AM

This is a very important issue that needs careful consideration and probably may apply to a number of SW Eng change requests - it is a reword of an existing IT/business focussed skill, and overlap, or a uniques skill (which may seem to duplicate an existing one). This is perhaps the perfect example of this issue.

I don't think this is about 'old-fashion up-front' vs '(presumably modern) agile', this is about ensuring that two communities, with very different DNA, who both build systems using software being able to use the framework effectively without too much interpretation. We also need to consider how the two communities will see our solution (whatever that might be) ... BAs hate to think of themselves as engineers (or use the word engineering) and engineers would hate to see the importance of engineering diluted for the business community.

Some interesting discussions to be had on this one.