Challenging Universal Truths of Requirements Engineering
Total Page：16
File Type：pdf, Size：1020Kb
Point - Counterpoint Challenging Universal Truths of Requirements Engineering Because requirements engineering is Likely to be a major issue in this decade, now is a good time to examine two widely held beliefs: Requirements describe a system’s “what,” not its “how.” Requirements must be represented as abstractions. JAWED Srmiar, Sheffield-Hallam University fa system, not the “bow.” gence of significant ideas in soft- It is generally accepted that a re- ware development, simply track quirements document contains a what part of the idealized life cycle description of what the system will has gotten all the attention over the do without describing how it will years: In the ’60s, it was coding; in do it.’ Alan Davis calls this the the ’70s, design; in the %Os, specifi- “what-versus-how paradox:” Most cation. popular approaches to require- Of course, all these issues have ments engineering solve the prob- always been important and major lem of requirementsengineeringin contributions are not restricted to a unique way. these decades, but it was during We can make sense of this para- these times that each activity dox by observing that each solution emerged as a subject in its own is one level in a hierarchy of ab- right, with its own community of straction levels, distinguished by activists. the extent that it abstracts require- I think most would agree that ments. As Davis said, “one person’s requirements engineeringwill be a ‘how’ is another person’s ‘what.”’ critical issue in the ’90s. And it has An intermediate level is both the certainly attracted its share of mis- “how” of the level above it and the sionaries! In this essay, I explore “what” of the level below it.’ two of the so-called universal truths This appears to solve the prob- of requirements engineering, to lem, but it leaves unresolved the stimulate discussion and challenge question ofwhether or not it is pos- Current thinlung. sible or desirable to separate the quirements is overwhelmingly “what” from the “how” in practice. more popular than what Harold FIRST UNIVERSAL TRUTH The essence of this evokes the Abelson and Gerald Sussman have , debate over structured Dropram- Repiremats describe the ‘bbat” ming in the 1970s. Thin, strut- ~ ~ ~ MARCH 1994 “classical mathematical” viewpoint em- that can be abstracted. It also implies that gral to most scientific disciplines- what bodied in declaration^.^ requirements methods are free of as- are we left with? Others have questioned the entire sumptions. We are left with the view that require- premise of the what-how debate. William Matthew Bickerton and I have contra- ments elicitation should not be based on Swartout and Robert Balzer have written dicted these implied characteristics.6We capturing the needs of individual users. that separating the specificationfrom the believe that assumptions about things hke Instead, it should focus on the interaction implementation is “overly naive and does organizations and society invariably be- of participants(social) rather than individ- not match realitv.... ,I SDecifications and im- come embedded in the ual participants (cogni- plementations are, in fact, intimately in- requirements method as tive). tertwined because they are respectively, it is developed. There- WE SHOULD Along these lines, the already-fixed and yet-to-be done por- fore, not only are such Goguen and Charlotte tions of multistep de~elopment.”~ methods not assump- FOCUS ON Linde have enumerated In a similar vein, Joseph Goguen has tion-free, their applica- INTERACTIONS the limitations of tradi- argued ‘(the belief that the steps of a life , tion cannot result in the tional elicitation tech- cycle should be executed sequentially is a same solution. AMONG USERS niques (interviews, ques- crude form of the myth that there is more ~ However, when we tionnaires, and protocol or less a unique best system to be bdt.”’ place today’s most popu- AND NOT ON analyses) and propose that According to Goguen, it is better to hnk lar methods into a taxon- INDlVl DUAL we can improve accuracy of requirements as “...emergent, in the omy, they all tend to fall by using conversational, sense that they do not already exist, but , into the same class: ra- USERS. interaction, and discourse rather emergev from interactions between , tional functionalism.6 analyses instead.8 the analyst and the client organization.” oes the requirements-engineering SECOND UNIVERSAL TRUTH Dcommunity need to completely reori- ent itself toward this new, social, integrat- Requirements shozlld be represented as ab- ed perspective? No, but I am suggesting srvactions. that adopting a social perspective will let Requirements modeling involves constructed as a result of interactions us uncover elements that a purely tech- using abstractions to produce a view of the among participants in the requirements cal perspective will miss. system that is independent of the method There is thls conundrum: The social and notation used. Indeed, implicit in perspective requires that we ground our Davis’ exposition of the what-how para- observations in real-world settings, yet dox is the notion that all models vary only system development requires formalism in their level of decomposition.This im- and abstraction. This then is the thorny plies that there is some objective reality problem facing requirements engineer- ing. + ACK”TS Many of these ideas have originated from my close collaboration and friendship with Alan Davis and Jawed Siddiqi is the direc- Joseph Goguen - I am indehted to hoth. Any misrepresentation of their ideas is, of course, com- tor of the Computing Re- pletely my responsibility. search Centre at Sheffield- Hallam University He is REFERENCES also a visiting researcher at the Centre for Require- I. A.M. Davis, Sojiware Requirements:O@ects, Functions and States, Prentice-Hall, Englewood Cliffs, ments and Foundations at NJ., 1993. the Oxford University 2. I.J. Hayes and C.B. Jones, “Specifications are Not (Necessarily) Executable,” Software Eng. y., Computing Laboratory. Nov. 1989, pp. 330-338. His research interests are 3. H. Abelson and G.Sussman, The Stmctere and Interpretution uf’Cornpster Prugrams, McGraw-Hill, software engineering, the human factors of software New York, 198s. development, requirements engineering, and anima- 4. W Swartout and R. Balzer, “On the Inevitable Intertwining of Specifications and Implementa- tion of formal Specification. tions,” Comm. ACM, July 1982, pp. 438-440. Siddiqi received a BS in mathematics from the 5. J. Goguen, “Requirements Engineering: Reconciliation of Technical and Social Issues,” tech. re- University of London and an MS and a PhD in port, Centre for Requirements and Foundations, Oxford University Computing Lab, Cambridge, computer science from the University of Aston in U.K., 1902. Birmingham. He is a member of the British 6. M.Bickerton and J. Siddiqi, “The Classification of Requirements Engineering Methods,” PYOC. Computer Society and the IEEE Computer Society. Inr’lSymp. RequirenlentsEng., IEEE CS Press, Los Aamitos, Calif., 1993, pp. 182-186. His address is Shefield-Hallam University, 7. C. Floyd et al., Software Developmmtand Reality Comtmctiun, Springer Verlag, Berlin, 1991. School of Computing and Management Science, 8. J.A. Goguen and C. Linde, “Techniques for Requirements Elimination,” Proc. Int’l Symp. Ke- Hallamshire Business Park, 100 Napier St., Shefield quirements Eng., IEEE CS Press, Los Alamitos, Calif., 1993, pp. 152-164. S11 8HD, UK; [email protected]. ~ ~ ~~ IEEE SOFTWARE 19 .