3

I would like to know what documents (ISO?) should I follow when I write a functional specification. Or what should designers follow when creating the system design? I was told that there was a progress in last years but was not told what the progress was in (college professor). Thank you

EDIT: I do not speak about document content etc. but about standards for capturing requirements, for business analysis.

Improve this question
3
  • 2
    most organisations will have their own templates, standard layout, expected content, etc. I don't think the real world posseses a one-size-fits-all solution. Commented Sep 19, 2012 at 13:43
  • Hmm what about ISO 12207 ? It defines processes that need to be done etc. Commented Sep 19, 2012 at 13:44
  • "There are 23 Processes, 95 Activities, 325 Tasks and 224 Outcomes (the new "ISO/IEC 12207:2008 Systems and software engineering – Software life cycle processes" defines 43 system and software processes)." - Uh-oh. I may be biased but this sounds like a surefire way never to deliver anything even remotely usable to the customer :-/ Commented Sep 19, 2012 at 13:49

3 Answers 3

Reset to default
5

I'm more of a CMMI fan, but that might be because I've gone through the pain of getting to level 3 -- on what was originally a research project. "If we knew what we were doing we wouldn't call it research." That's a bit counter to the concepts of to any those software quality / process improvement efforts. I've also been with organizations that became ISO 9001 certified.

Both CMMI and ISO can be a bit (more than a bit!) burdensome. Getting certified at CMMI-DEV 3 is costly, in dollars and in time. Quality is not free. (At least that silly management mantra went out the door.) IMO, CMMI level 2 is a reasonable target for most organizations; CMMI 3 is where you start to need to be very sure the product is right. CMMI 4 and beyond: I wouldn't want to work there. The stuff I work on, if done wrong, could lead to hundred of million dollar catastrophes. Research project quality, or even CMMI 2, was not good enough. CMMI 4 was (thankfully) deemed too counterproductive.

Improve this answer
3
  • Yup, CMMI is a good system - especially with the differing levels. I understand that the new TickIT+ (ISO90003/ISO15504) QA system has a layered approach too. Commented Sep 20, 2012 at 10:55
  • Phil Crosby is the one who came up with the "Quality is free" idea. He wrote a book about it. The point of the mantra is that you can spend some money up-front, to do it right the first time, or you can spend MORE money down the road correcting the mistakes. It is CHEAPER to do it right the first time, hence "Quality is free", because it costs LESS to do it RIGHT than you spend doing it wrong and doing it over. Phil wrote a book and the book is worth reading. (Full Disclosure: It was required reading for all engineers at Texas Instruments Defense ca. 1990.) Commented Sep 20, 2012 at 15:59
  • Sure, "quality is free" -- If you are starting from CMMI level -1 (there is no such beast, at least not officially), with not one thought toward software quality. A tiny investment in improving quality will have a many-fold ROI at this level. But quality is not free once you get past that base level. Improved quality does come at a cost. Crosby was writing about that part of the cost/benefit curve where the return on investment is positive. That positive ROI may not be the case for an organization that is already paying attention to quality. Commented Sep 20, 2012 at 18:42
2

Ok, I'll be controversial here:

Literally no project I have worked on in the last 10 years has used or derived value from classic ISO style functional specs (and this includes government, finance and medical industry).

Most efficient software houses these days use User Stories as the basis to express requirements possibly supported where required by light UML style diagrams as well as UX artefacts (wireframes). In addition in-code documentation and (self)documenting APIs (think 'Swagger') provide the needed documentation on the technical side.

Using tools such as JIRA or VSTS one can automate the process of collating these across a release and ensuring traceability so that these lightweight 'specs' can be collated (automatically) for compliance / regulatory purposes.

The reason I am passionate about such lightweight ways of documenting is that I have yet to see classical functional / technical specs the get actually updated and stay relevant.

There may be cases where classic specs are needed, but I am yet to be convinced that this is really true (beyond it being simply a bureaucratic requirement).

Improve this answer
1

I can endorse following the ISO12207 life-cycle model referred to above

Specifically, to answer the question though, the IEEE are the answer with IEEE Std 830-1998 - this is written with 12207 in mind

@Peter is quite dismissive of ISO12207, but for anything safety critical, documentation is paramount... but I accept for many applications it will be OTT.

Update 2012-11-12

Re-reading the question, ISO12207 is the Software Development Life-Cycle process model which covers all phases (as does CMMI)... the question specifically asks about writing a functional specification.

There is, naturally, an ISO standard for that too: ISO/IEC/IEEE 29148:2011 Systems and software engineering -- Life cycle processes -- Requirements engineering, quoting the Abstract:

ISO/IEC/IEEE 29148:2011 contains provisions for the processes and products related to the engineering of requirements for systems and software products and services throughout the life cycle. It defines the construct of a good requirement, provides attributes and characteristics of requirements, and discusses the iterative and recursive application of requirements processes throughout the life cycle.

ISO/IEC/IEEE 29148:2011 provides additional guidance in the application of requirements engineering and management processes for requirements-related activities in ISO/IEC 12207:2008 and ISO/IEC 15288:2008.

Information items applicable to the engineering of requirements and their content are defined. The content of ISO/IEC/IEEE 29148:2011 can be added to the existing set of requirements-related life cycle processes defined by ISO/IEC 12207:2008 or ISO/IEC 15288:2008, or can be used independently.

Improve this answer
2
  • Yeah, I can accept that for life- or mission-critical software, such rigorous processes are in place. I have no experience with stuff like that though. I have worked (and am working) on business critical enterprise software where a failure may cost dearly (read: many thousands of Euros/dollars), but for these, much less strict (and more agile) processes were and are adequate in my experience. Thus in general, for the vast majority of projects out there, such standards are IMHO overkill. Commented Sep 20, 2012 at 7:54
  • I endorse the ISO/IEC/IEEE 29148:2011 , standards.ieee.org/findstds/standard/29148-2011.html Commented Oct 31, 2014 at 18:40

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.