An In-Depth Study on Requirement Engineering by ijcsis

VIEWS: 109 PAGES: 11

									                                                         (IJCSIS) International Journal of Computer Science and Information Security,
                                                                                                        Vol. 8, No. 8, November 2010

      An In-depth Study on Requirement Engineering
             Mohammad Shabbir Hasan1, Abdullah Al Mahmood2, Farin Rahman3, Sk. Md. Nahid Hasan 4
                                    Panacea Research Lab, Dhaka, Bangladesh

Abstract— Software development includes Requirement                     constrained by a variety of factors outside their control.
Engineering (RE) which is comprised of discovering                      Based on these characteristics Zave [3] defined RE as:
stakeholders and their need, proper documentation,
communication and subsequent implementation. It can be                      “Requirements engineering is the branch of
viewed as the most crucial phase as the success of the software
                                                                            software engineering concerned with the real-
depends largely on it. Requirement Engineering is receiving
increasing attention of the researchers and also people                     world goals for, functions of, and constraints on
associated with software development. This paper investigates               software systems. It is also concerned with the
RE activities in detail followed by some current challenges and             relationship of these factors to precise
also proposes some suggestions to overcome these challenging                specifications of software behavior, and to their
issues.                                                                     evolution over time and across software
   Keywords- Software Requirement, Requirement Engineering,
Requirement Elicitation, Requirement Management.                            This definition is an attractive one as it highlights the
                                                                        importance of “real world goals” which motivates the
                     I.    INTRODUCTION                                 development of a software system by referring the
    Success of a software system is measured by evaluating              specifications more precisely. It also refers to the reality of a
how it meets the purpose it was intended and in broad sense,            changing world and the need to reuse partial specifications,
Requirement Engineering (RE) is the process of discovering              as done by engineers in other branches of engineering.
that purpose through identifying stake holders and their                Brooks [4] defined RE as a key problem area in the
needs, refinement of the gathered information, modeling,                development of complex, software-intensive systems:
specification and then subsequent implementation. The
system requirements and role allocated to software—                         “The hardest single part of building a software
initially established by the system engineer—are refined in                 system is deciding what to build. ...No other
detail. Models of the required data, information and control                part of the work so cripples the resulting system
flow, and operational behavior are created. Alternative                     if done wrong. No other part is more difficult to
solutions are analyzed and a complete analysis model is                     rectify later.”
created [1]. Donald Reifer [2] describes the software
requirement engineering process in the following way:                        RE can be characterized as a branch of System
                                                                        Engineering [5] as it has to encompass a systems level view
    “Requirements engineering is the systematic use                     to deliver some systems behavior to its stakeholders. Again,
    of proven principles, techniques, languages, and                    Zave defined RE as a branch of Software Engineering and
    tools for the cost effective analysis,                              software systems requirements engineering has received
    documentation, and on-going evolution of user                       special consideration possibly due to the abstract and
    needs and the specification of the external                         invisible nature of software with the vast range and variety
    behavior of a system to satisfy those user needs.                   of problems that admit to software solutions.
    Notice that like all engineering disciplines,                          Whether viewed at the systems level or the software
    requirements engineering is not conducted in a                      level, RE is a multi-disciplinary, human-centered process
    sporadic, random or otherwise haphazard fashion,                    and the use of the term Engineering in RE serves as a
    but instead is the systematic use of proven                         reminder that RE is an important part of an engineering
    approaches.”                                                        process and represents a series of engineering decisions that
                                                                        lead from recognition of a problem to be solved to a detailed
     The Requirement Engineering process may face a                     specification of that problem followed by anchoring
number of inherent difficulties like: stakeholders may be               development activities, so that the appropriateness and cost-
numerous and distributed, their goals may be volatile and               effectiveness of the solution can then be analyzed.
conflicting, depending on their perspectives of different                   The structure of the paper is approximately as follows. In
working environment, goals may be implicit and difficult to             sections 2 and 3 we discuss the foundation and some ground
articulate, and, inevitably, satisfaction of these goals may be         works needed for requirement engineering respectively.

                                                                                                     ISSN 1947-5500
                                                       (IJCSIS) International Journal of Computer Science and Information Security,
                                                                                                      Vol. 8, No. 8, November 2010

Section 4 discusses about some key issues followed by the             requirements elicitation, for instance to analyze
core activities of RE in section 5. Then, in section 6,               communication patterns within an organization [13].
challenges of RE activities are analyzed with some                    Philosophical elements also have an important effect on RE
suggestions. We finish by drawing some broad and                      as it is concerned with interpreting and understanding of
necessarily speculative and personal conclusions about the            terminology, concepts, viewpoints and goals from
future of requirement engineering.                                    stakeholder’s perspective. Such issues become important
                                                                      while requirement validation, especially where stakeholders
                     II.   FOUNDATION                                 may have divergent goals and incompatible belief systems.
     RE activities play a vital role in software and systems          They also become important in selecting a requirement
engineering, and there are also many disciplines upon which           modeling technique, because the choice of technique affects
it draws.                                                             the set of phenomena that can be modeled, and may even
      In software development context, an important role is           restrict what a requirements engineer is capable of observing
played by Computer Science as theoretical computer science            [6].
provide the framework to assess the feasibility of                                        III.   GROUNDWORK
requirements while the means of developing software
solution are provided by practical computer science. Here                  In the software development process, RE is considered
logic provides a vehicle for analyzing software behavior              as a front-end activity. Although it is usually the case that
which is acquiescent to formal reasoning to make the                  requirements change during development and evolve after a
reasoning steps more explicit. Different logics may be used           system has been in operation for some time, RE plays an
to express different aspects of a required system. For                important role in the management of changes in software
example, temporal logic can be used to describe timing                development. Nevertheless, the bulk of the effort of RE does
information, deontic logic to describe permissions and                occur early in the lifetime of a project, motivated by the
obligations, and linear logic to describe resources and their         evidence that requirements errors, such as misunderstood or
use. A further advantage of specification languages                   omitted requirements, are more expensive to fix later in
grounded in logic is that they are potentially amenable to            project lifecycles [14-15].
automated reasoning and analysis [6].                                      Before a project can be started, some preparation is
     In the systems engineering context, an understanding             needed which are categorized as context and groundwork by
and application of systems theory and practice is also                Finkelstein [16]. This groundwork includes some
relevant to RE [5]. This includes work on characterizing              assessment of project’s feasibility and associated risks needs
systems, identifying their boundaries and managing their              to be undertaken, and RE plays a crucial role in making
development life cycle [7-8]. RE also encompasses work on             such an assessment. Although it is often possible to estimate
systems analysis, traditionally found in the information              project costs, schedules and technical feasibility from
systems world [9].                                                    precise specifications of requirements, risk should be re-
    Usually RE activities take place in a human activity              evaluated regularly throughout the development lifetime of
system, and people are the problem owner. Therefore, RE               a system [17], since changes in the environment can change
needs to be sensitive to how people perceive and understand           the associated development risks.
the newly implemented computer-based system, how they                     Again, RE activities are performed in a variety of
interact, and how the environment of the workplace is                 contexts, including market-driven product development and
affected by their actions. RE draws on the cognitive and              development for a specific customer with the eventual
social sciences to provide both theoretical grounding and             intention of developing a broader market. The type of
practical techniques for eliciting and modeling requirements          product also affects the choice of method: RE for
[6]. Cognitive psychology provides an understanding of the            information systems is very different from RE for embedded
difficulties people may have in describing their needs [10].          control systems, which is different again from RE for generic
Anthropology provides a methodological approach to                    services such as networking and operating systems [6]. So
observing human activities that helps to develop a richer             groundwork is essential for the identification of a suitable
understanding of how computer systems may help or hinder              process and also for the selection of suitable methods and
those activities [11]. Sociology provides an understanding of         techniques for the various RE activities.
the political and cultural changes caused by computerization.
Introduction of a new computer system changes the nature of                IV.    KEY ISSUES IN REQUIREMENT ENGINEERING
the work carried out within an organization, may affect the               Software development organizations should keep in
structure and communication paths within that organization,           mind the following issues when they consider how to
and may even change the original needs that it was built to           improve the requirements and communication for their
satisfy [12]. Linguistics is important because RE is largely          projects:
about communication. Linguistic analyses have changed the                 • If teams don’t get requirements right, it doesn’t
way in which the English language is used in specifications,                    matter how well they execute the rest of the
for instance to avoid ambiguity and to improve                                  project: The goal of every software development
understandability. Tools from linguistics can also be used in                   project is to build a product that provides value to

                                                                                                 ISSN 1947-5500
                                                    (IJCSIS) International Journal of Computer Science and Information Security,
                                                                                                   Vol. 8, No. 8, November 2010

    customers. Effective requirements definition                             stakeholders. Further teams that can force as much
    enables teams to determine the mix of product                            change at the beginning of a project will have less
    capabilities and characteristics that will best deliver                  change to manage over time [18].
    this customer value. An understanding evolves                      •    Teams are never going to have perfect
    over time as stakeholders provide feedback on the                       requirements: Requirements are never finished or
    early work and refine their expectations and needs.                     complete. There is no way to know for certain that
    Adequately exploring and crafting requirements                          teams have not overlooked some requirement, and
    into a set of product features and attributes helps to                  there will always be some requirements that are not
    ensure customer needs are being met throughout                          in the specification. It is also folly to think teams can
    the project lifecycle [18].                                             freeze the requirements and allow no changes after
•   Requirements definition is a discovery and                              some initial elicitation activities. Rather than
                                                                            declaring requirements “done” at some point,
    invention process, not just a collection process:
                                                                            effective teams define a baseline then follow a
    Teams often talk about “gathering requirements.”
                                                                            sensible change control process to modify
    This phrase suggests that requirements are just                         requirements once a baseline is established [18].
    lying around waiting to be picked like flowers or to
    be plucked out of users’ brains by an analyst. In                  V.    CORE ACTIVITIES OF REQUIREMENT ENGINEERING
    reality, requirements definition is an exploratory
                                                                         Good RE activities can accelerate software
    activity, and requirements elicitation is a more
                                                                    development. The process of defining business requirements
    accurate description than requirements gathering.
                                                                    aligns the stakeholders with shared vision, goals and
    Elicitation includes some discovery and some
                                                                    expectations. Involvement of substantial user in establishing
    invention, as well as recording those bits of
                                                                    and managing changes to agree upon requirements increases
    requirements information that various stakeholders
                                                                    the accuracy of requirements, ensuring that the functionality
    present to an analyst. Elicitation demands iteration.
                                                                    of the developed system will enable users to perform their
    Constant      feedback      and    validation     from
                                                                    essential business tasks.
    stakeholders keeps communication flowing.
                                                                         In a broad sense, Requirement Engineering
    Participants in a requirements elicitation discussion
                                                                    encompasses the two major sub domains of requirement
    will not think of everything they will need up front,
                                                                    definition and requirement management.
    and their thinking will change as a project
                                                                         Requirement Definition is the collaborative process of
    progresses. Teams that prepare to iterate most often
                                                                    collecting, documenting and validating a set of requirements
    elicit the most accurate requirements [18].
                                                                    that constitute an agreement among key project
•   Customer involvement is the most critical                       stakeholders. This phase can be further subdivided into the
    contributor to software quality: Various studies                critical process areas of elicitation, analysis, specification,
    confirm that inadequate customer involvement is a               agreeing and validating requirements.
    leading cause of failure of software projects. The                   From a pragmatic perspective, requirement definition
    development team will get the customer input it                 strives for requirements which are validated by user and
    needs eventually – even if it is after a project ships.         clear enough to the software development team to proceed
    However, it is much cheaper – and much less                     with design, construction and testing at an acceptable level
    painful – to get customer input earlier, rather than            of risk. It is natural that, risk leads to the threat of doing
    after product release. Customer involvement                     expensive and unnecessary rework.
    requires more than a workshop or two early in the                    Requirement Management involves working with a
    project. It involves input from customers early and             defined set of requirements throughout the development
    often in the requirements process. Ongoing                      process of the system and its operational life. It also allows
    engagement by suitably empowered and                            managing changes to that set of requirements throughout the
    enthusiastic stakeholders is a critical success factor          project lifecycle. This phase includes selecting changes to
    for software development [18].                                  be incorporated within a particular release and ensuring
•   Change happens; managing change is critical: It                 effective implementation of changes with no adverse impact
    is inevitable that requirements will change as                  on schedule, scope or quality of the developed system.
    business needs evolve, new users or markets are                      An effective requirement definition and management
    identified, business rules and government                       solution creates an accurate and complete set of system
    regulations are revised and operating environments              requirements, while helping organizations to improve
    change. The objective of a change control process               communications is an effort to better align it with business
    is not to inhibit change. Rather, the objective is to           needs and objectives. The following sub sections discuss the
    manage change to ensure that the project                        core activities of RE.
    incorporates the right changes for the right reasons.
    Teams that anticipate and accommodate changes
    minimize disruption and cost to the project and its

                                                                                                ISSN 1947-5500
                                                         (IJCSIS) International Journal of Computer Science and Information Security,
                                                                                                        Vol. 8, No. 8, November 2010

A. Requirement Elicitation                                                       homogeneous, and hence part of the elicitation
     Requirements elicitation is recognized as one of the                        process is to identify the needs of different user
most critical, knowledge-intensive activities of software                        classes, such as novice users, expert users,
development [19]; poor execution of elicitation will lead a                      occasional users, disabled users, and so on [22]. So
complete failure of the project. Since project failures are so                   initially every software project should identify its
rampant [20], it is quite likely that improving how the                          key requirement decision makers as well as the
industry performs elicitation could have a dramatic effect on                    decision-making process to ensure that the right
the success record of the industry [21]. Information                             people can make important and timely decisions.
collected during this requirement elicitation phase are                     •    Select Elicitation Technique: The choice of
interpreted, analyzed, modeled and validated so that a                           elicitation technique depends on the time and
requirement engineer can feel confident that a complete                          resources available to the requirements engineer,
enough set of requirements of a system have been collected.                      and of course, the kind of information that needs to
Therefore, requirements elicitation is closely related to other                  be elicited [6]. It also depends on the extent of
RE activities – to a great extent, selection of techniques for                   stakeholder involvement and how much access the
the next phases largely depends on how requirements were                         analyst has to the stakeholders. To interact with
elicited. Steps in requirement elicitation phase are described                   stakeholders, requirement engineer can use
below:                                                                           techniques like: workshops, questionnaires, and
     • Defining System Boundaries: One of the key                                interviews. Now a day, it is a common practice that
          objectives of requirement elicitation is to define                     teams want to interact with stakeholders in
          system boundaries i.e., to find out the problems                       lightweight, dynamic, frequent way which is
          that need to be solved. This definition is necessary                   completely focused on the problem and thus
          to discover where the final delivered system will fit                  collaboration      has     taken       priority     over
          into the current operational environment. Without a                    documentation review. Techniques that leverage
          clearly defined system boundary, the project is                        prototypes, mockups and screenshots are becoming
          issuing an open invitation to scope creep. Prior to                    the norm. However, for the sake of a dynamic
          eliciting requirements, teams should have a clear                      development process, teams should be trained and
          understanding of system boundaries as it affects all                   proficient in a variety of elicitation techniques.
          subsequent elicitation efforts.                                   •    Exploring user scenarios and simulations: It is
     • Defining Goals: Goals denote the objectives that a                        often the case that users find it difficult to articulate
          system should meet. Eliciting high level goals in                      their requirements. Rather they find it more
                                                                                 convenient to visually describe their business tasks,
          the early stage of the development process is
                                                                                 interaction patterns and expected product
          crucial. However, goal-oriented requirements
                                                                                 functionality than to define all these textually. So a
          elicitation [23] is an activity that continues as                      requirements engineer can resort to eliciting
          development proceeds, as high-level goals (such as                     information about the tasks currently performed by
          business goals) are refined into lower level goals                     the users and those that they might want to perform
          (such as technical goals that are eventually                           [24]. After that, these tasks can be represented in
          operational in a system) [6]. Eliciting goals                          use cases which can be used to describe the
          emphasizes on defining the problem domain and                          outwardly visible requirements of systems [25].
          also the needs of the stakeholders, rather than on                     More specifically, the requirements engineer may
          possible solutions to those problems.                                  choose a particular path through a use case, a
     • Identifying Stakeholders: Stakeholders mean                               scenario, in order to better understand some aspect
          individuals or organizations that stand to gain or                     of using a system [26]. Acceleration in visual
          lose from the success or failure of a system.                          techniques for requirements definition and the
          Stakeholders include customers or clients (who pay                     ability to tie artifacts to more traditional
          for the system), developers (who design, construct                     requirements is changing the way of interactions
          and maintain the system), and users (who interact                      forming between business and development
          with the system to get their work done) [6]. It is                     organizations.
          essential to gain commitment from key                         A-1. Elicitation Techniques:
          stakeholders for their participation throughout the                Researchers found various classes for requirement
          requirements definition and Customer engagement               elicitation techniques all of which are apposite in different
          is necessary during requirements management, as               scenarios. Some of these are briefly discussed below:
          well. [18]. Stakeholders’ view is required in
                                                                             • Traditional Techniques: These techniques are
          making change in decisions followed by assessing
                                                                                  useful for gathering generic data. Questionnaires
          the impact of proposed changes and adjusting
                                                                                  and surveys, interviews, and analysis of existing
          requirement priorities. Users themselves are not
                                                                                  documentation (ex: organizational charts, process

                                                                                                    ISSN 1947-5500
                                                         (IJCSIS) International Journal of Computer Science and Information Security,
                                                                                                        Vol. 8, No. 8, November 2010

          models or standards, and manuals of existing                  engineering and software design. It allows the requirement
          systems) belong to this group.                                engineer to refine the software allocation and build models
     • Elicitation through Groups: These techniques are                 of the data, functional, and behavioral domains that will be
          useful for a richer understanding of need through             exploited by software. It is also beneficial for the software
          exploiting team dynamics with an aim to foster                designer as it provides a representation of information,
          stakeholders’ need. This class includes techniques            function, and behavior that can be translated to data,
          like brainstorming and focus groups, as well as               architectural, interface, and component-level designs.
          RAD/JAD workshops (using consensus-building                   Finally, requirements specification after successful
          workshops with an unbiased facilitator) [27].                 requirement analysis provides the developer as well as the
     • Prototyping: These techniques are useful in such                 customer with the means to assess quality once software is
          cases where there remains a great deal of                     built. The subsequent steps should be followed during
          uncertainty about the requirements, or where early            requirement analysis:
          feedback from stakeholders is needed [28]. For                     • Creation of visual scenarios: The natural language
          better requirement elicitation, prototyping can also                   requirements found in most specifications are
          be readily combined with other techniques, for                         mostly text based, full of ambiguities, redundancies
          instance by using a prototype to provoke discussion                    and gaps. Most of the cases, it is desirable to
          in a group elicitation technique or as the basis for                   represent requirements in multiple ways to give
          other traditional techniques.                                          readers a richer, more holistic understanding.
     • Model Driven Techniques: Techniques of this class                         Visual scenarios present requirements information
          is helpful in the cases where a specific model of the                  from a business viewpoint in graphical diagrams
          type of information to be gathered is already                          which allow reviewers to immediately spot missing
          provided and this model is used to drive the                           requirements by examining flows, rather than
          elicitation process. Goal-based methods, such as                       uncovering missing requirements by reading a
          KAOS [29] and I* [30], and scenario-based                              opaque textual specification. Teams may have
          methods such as CREWS [31] belong to this class.                       better results using diagrams that communicate at a
     • Cognitive Techniques: This group includes a series                        higher level of abstraction, so readers can get the
          of techniques originally developed for knowledge                       big picture without getting mired in all of the
          acquisition for knowledge-based systems [32].                          details.
          Such techniques include protocol analysis (in                      • Creation and Evaluation of Simulations: A
          which an expert thinks aloud while performing a                        simulation is an interactive software experience
          task, to provide the observer with insights into the                   that captures the essential flow and level of detail
          cognitive processes used to perform the task),                         to the requirements. Simulations provide
          laddering (using probes to elicit structure and                        opportunities for everyone to interact with some
          content of stakeholder knowledge), card sorting                        portion of the final system which is more tangible
          (asking stakeholders to sort cards in groups, each                     than written requirements specifications. A
          of which has name of some domain entity),                              simulation may look and behave like a prototype,
          repertory grids (constructing an attribute matrix for                  but the key difference is that a simulation is not
          entities, by asking stakeholders for attributes                        created by the development team. It is created as
          applicable to entities and values for cells in each                    part of the requirements definition phase and is
          entity) [6].                                                           typically done without requiring any development
     • Contextual Techniques: This class is an alternative                       skills. Simulations can leverage existing business
          to both traditional and cognitive techniques [33].                     data, show flow of the data and dynamically
          These include the use of ethnographic techniques                       capture feedback that can quickly be incorporated
          like participant observation, ethnomethodogy and                       into the next revision. Typically, revisions can be
          conversation analysis, which result fine grained                       augmented during the stakeholder review – leading
          analysis to identify patterns in conversation and                      to an “Is this what you had in mind?” high quality
          interaction [34].                                                      interaction [18].
Though there is a fundamental methodological disagreement                    • Requirement Prioritization: The ultimate goal of a
between the proponents of contextual techniques on the one                       software development team is to create a system
hand, and the traditional and cognitive techniques on the                        that meets the stakeholders’ demands. Since there
other, recent work has focused on the question of whether                        are usually more requirements than can be
integration is possible [34-35].                                                 implemented within the limited resource, decision
B. Requirement Analysis                                                          makers must face the dilemma of selecting the
                                                                                 right set of requirements for the intended system.
    Requirements Analysis is a fundamental activity in RE                        In order to select the correct set of requirements,
that bridges the gap between system level requirements                           the decision makers must understand the relative

                                                                                                   ISSN 1947-5500
                                                          (IJCSIS) International Journal of Computer Science and Information Security,
                                                                                                         Vol. 8, No. 8, November 2010

         priorities of the requested requirements [36]. By                       •  It decomposes the problem into component parts.
         selecting a subset of the requirements that are                            The simple act of writing down software
         valuable for the customers, and can be                                     requirements in a well-designed format organizes
         implemented within budget, organizations can                               information, places borders around the problem,
         become more successful on the market. However,                             solidifies ideas, and helps break down the problem
         Prioritization should be a collaborative process that                      into its constituent parts in an orderly fashion.
         involves both a customer and a technical                              • It serves as an input to the design specification. As
         perspective to balance customer value against cost                         mentioned previously, the SRS serves as the parent
         and technical risk.                                                        document to subsequent documents, such as the
    Analysis techniques that have been investigated in RE                           software design specification and statement of
include requirements animation [37], automated reasoning                            work. Therefore, the SRS must contain sufficient
(e.g., analogical and case-based reasoning [38] and                                 detail in the functional system requirements so that
knowledge based critiquing [39]), consistency checking (e.g.,                       a design solution can be devised.
model checking [40]), and a variety of techniques for                         It serves as a product validation check. The SRS also acts
validation and verification.                                              as the parent document for testing and validation strategies
C. Requirement Specification                                              that will be applied to the requirements for verification and
    Software Requirement Specification (SRS) is basically
an organization's understanding (in writing) of a customer or             C-2.   What should the SRS address?
potential client's system requirements and dependencies at a                   IEEE standards suggest that SRS should address the
particular point in time (usually) prior to any actual design or          following basic issues:
development work. It's a two-way insurance policy that
                                                                               • Functionality: What is the software supposed to
assures that both the client and the organization understand
the other's requirements from that perspective at a given                         do?
point in time. The SRS document itself states in precise and                   • External interfaces: How does the software interact
explicit language those functions and capabilities a software                     with people, the system’s hardware, other
system must provide, as well as states any required                               hardware, and other software?
constraints by which the system must abide. The SRS also                       • Performance: What is the speed, availability,
officiates as a blueprint for completing a project with as little                 response time, recovery time of various software
cost growth as possible. The SRS is often referred to as the                      functions, etc.?
"parent" document because all subsequent project                               • Attributes: What are the portability, correctness,
management documents, such as design specifications,                              maintainability, security, etc. considerations?
statements of work, software architecture specifications,                      • Design constraints imposed on an implementation:
testing and validation plans, and documentation plans, are                        Are there any required standards in effect,
related to it. It is important to note that an SRS contains                       implementation language, policies for database
functional (requirements that define a function of a software                     integrity, resource limits, operating environment(s)
system or its component) and nonfunctional requirements                           etc.?
(requirements that specify criteria that can be used to judge
the operation of a system, rather than specific behaviors)                C-3.   Characteristics of a good SRS
only; it doesn't offer design suggestions, possible solutions to              A good SRS should contain the following
technology or business issues, or any other information other             characteristics:
than what the development team understands the customer's                     • Complete: SRS should define precisely all the go-
system requirements to be. There are some standard for SRS                         live situations that will be encountered and the
defined by IEEE e.g. IEEE STD 830-1998 [41] and IEEE
                                                                                   system's capability to successfully address them. It
STD 1233-1998 [42].
                                                                                   should contain everything that is needed by the
C-1.  Goals of SRS                                                                 software designers to develop the software.
    A well-designed, well-written SRS accomplishes four                       • Correct: Of course everyone associated with the
major goals:                                                                       intended system expects the specification to be
    • It provides feedback to the customer. An SRS is                              correct. No one writes a specification that they
        the customer's assurance that the development                              know is incorrect. Someone may like to say it -
        organization understands the issues or problems to                         "Correct and Ever Correcting." The discipline is
        be solved and the software behavior necessary to                           keeping the specification up to date when someone
        address those problems. Therefore, the SRS should                          finds things that are not correct.
        be written in natural language, in an unambiguous                     • Consistent: The SRS should be consistent within
        manner that may also include charts, tables, data                          itself and consistent to its reference documents. If
        flow diagrams, decision tables, and so on.                                 someone calls an input "Start and Stop" in one

                                                                                                     ISSN 1947-5500
                                                   (IJCSIS) International Journal of Computer Science and Information Security,
                                                                                                  Vol. 8, No. 8, November 2010

    place, he/she shouldn't call it "Start/Stop" in               C-4.       Benefits of a good SRS
•   Accurate: SRS should precisely define the system's               The IEEE 830 standard defines the benefits of a good
    capability in a real-world environment, as well as            SRS [41]:
    how it interfaces and interacts with it. This aspect                 •     Establish the basis for agreement between the
    of requirements is a noteworthy problem area for                           customers and the suppliers on what the software
    many SRSs.                                                                 product is to do: The complete description of the
•   Modifiable: The logical, hierarchical structure of                         functions to be performed by the software specified
    the SRS should facilitate any necessary                                    in the SRS will assist the potential users to
    modifications; grouping related issues together and                        determine if the software specified meets their
    separating them from unrelated issues makes the                            needs or how the software must be modified to
    SRS easier to modify.                                                      meet their needs.
•   Ranked: Individual requirements of an SRS should                     •     Reduce the development effort: The preparation of
    be hierarchically arranged according to stability,                         the SRS forces the various concerned groups in the
    security,       perceived      ease/difficulty     of                      customer’s organization to consider rigorously all
    implementation, or other parameter that helps in                           of the requirements before design begins and
    the design of that and subsequent documents.                               reduces later redesign, recoding, and retesting.
•   Unambiguous: SRS must contain requirements                                 Careful review of the requirements in the SRS can
    statements that can be interpreted in one way only.                        reveal     omissions,    misunderstandings,     and
    This is another area that creates significant                              inconsistencies early in the development cycle
    problems for SRS development because of the use                            when these problems are easier to correct.
    of natural language.                                                 •     Provide a basis for estimating costs and schedules:
•   Testable: SRS must be stated in such a manner that                         The description of the system to be developed as
    unambiguous assessment criteria (pass/fail or some                         given in the SRS is a realistic basis for estimating
    quantitative measure) can be derived from the SRS                          project costs and can be used to obtain approval for
    itself.                                                                    bids or price estimates.
•   Traceable: Requirements traceability (RT) is                         •     Provide a baseline for validation and verification:
    another major factor that determines how easy it is                        Teams can develop their validation and
    to read, navigate, query and change requirements                           Verification plans much more productively from a
    documentation [6]. SRS must be able to link each                           good SRS. As a part of the development contract,
    software functional requirement back to its origin,                        the SRS provides a baseline against which
    possibly a use case or business rule. Teams should                         compliance can be measured.
    embrace traceability information that connects                       •     Facilitate transfer: SRS makes it easier to transfer
    functional requirements to associated design                               the software product to new users or new
    elements, code segments and tests to accelerate                            machines. Customers thus find it easier to transfer
    debugging and software maintenance. As RT lies at                          the software to other parts of their organization,
    the heart of requirements management practice,                             and suppliers find it easier to transfer it to new
    providing RT in SRS is a means of achieving                                customers.
    integrity and completeness of requirement                            •     Serve as a basis for enhancement: Because the SRS
    documentation that has an important role to play in                        discusses the system but not the project that
    managing changes.                                                          developed it, the SRS serves as a basis for later
•   Valid: A valid SRS is one in which all parties and                         enhancement of the developed system. The SRS
    project participants can understand, analyze,                              may need to be altered, but it does provide a
    accept, or approve it. This is one of the main                             foundation for continued system evaluation.
    reasons SRSs are written using natural language.              D. Agreeing and Validating Requirements
•   Verifiable: A verifiable SRS is consistent from one
    level of abstraction to another. Most attributes of a             It is an arduous job to maintain agreement with all
    specification are subjective and a conclusive                 stakeholders as they have divergent goals. Validation is the
    assessment of quality requires a technical review by          process of establishing that the requirements elicited and
    domain experts. Using indicators of strength and              specified provide an accurate account of stakeholder
    weakness provide some evidence whether preferred              requirements. This activity is essential for resolving
    attributes are present or not.                                conflicts between stakeholders.
                                                                      Techniques such as inspection and formal analysis tend
                                                                  to concentrate on the consistency and completeness of the
                                                                  requirements. This approach is illustrated by SCR [43]
                                                                  which provides an automated checking of the formal model

                                                                                                 ISSN 1947-5500
                                                         (IJCSIS) International Journal of Computer Science and Information Security,
                                                                                                        Vol. 8, No. 8, November 2010

for syntactic consistency and completeness. On the other                requirement of stakeholders. Requirement Management
hand, techniques like prototyping, specification animation,             should go through the following steps:
and the use of scenarios are geared towards testing a                        • Manage Requirements Versions: As requirements
correspondence with the real world problem: have all the                         evolve during the course of a project, it is
aspects of the problem that the stakeholders regard as                           important to track the different versions of
important been covered?                                                          requirements specification documents and even
     In some cases, the methods and tools used by the                            individual requirements [18]. Changes to
requirement engineers dominate the way that they see and                         requirements documentation need to be managed
describe problems, which, in the extreme case, shifts the                        properly and minimally, this involves providing
problem of validating requirements statements to a problem                       techniques and tools for configuration management
of convincing stakeholders that the chosen representation                        and version control [51], and by exploiting
for requirements models is appropriate. This leads to the                        traceability, the impact of changes in different parts
realization that observation is not value free, rather it is                     of the documentation can be monitored and
theory-driven, and is biased by the current paradigm.                            controlled correctly. Version tracking helps to
Jackson captures this perspective through his identification                     ensure that all team members are working from the
of problem frames [44]. If stakeholders do not agree with                        latest requirements baseline.
the choice of problem frame, it is unlikely that they will                   • Establishing A Change Control Process: Typically,
ever agree with any statement of the requirements.                               changes to requirement specifications include
Ethnomethodologists attempt to avoid the problem                                 adding or deleting requirements, and also fixing
altogether, by refusing to impose modeling constructs on the                     errors. Requirements are added in response to
stakeholders [33]. By discarding traditional problem                             changing stakeholder needs that were missed in the
analysis tools, they seek to apply value-free observations of                    initial analysis. Requirements are deleted usually in
stakeholder activities, and therefore circumvent the                             the circumstances to forestall cost and schedule
requirements validation issue altogether.                                        overruns. Again there also remain some
     Requirements negotiation attempts to resolve conflicts                      inconsistencies in requirements which arise both as
on goal among stakeholders without necessarily weakening                         a result of mistakes and because of conflicts
satisfaction of each stakeholder. Early approaches to                            between requirements. In any case, managing
requirements negotiation focused on modeling each                                inconsistency in requirements specifications as
stakeholder’s contribution separately rather than trying to fit                  they evolve is a major challenge [52]. So once
their contributions into a single consistent model [45] and                      requirements have been base lined, proposed
on the importance of establishing common ground [46].                            modifications in them should follow an established
Boehm introduced the win-win approach [47] in which the                          change control process which provides consistency
win conditions for each stakeholder are identified, and the                      in the way requirement changes are proposed,
software process is managed and measured to ensure that all                      evaluated, approved or rejected, communicated to
the win conditions are satisfied, through negotiation among                      stakeholders and implemented in affected work
the stakeholders. These negotiation models concentrate on                        products. Teams should have formal written
the identification of the most important goals of each                           change control processes in place before eliciting
participant, and ensure that these goals are met. This                           requirements [18].
approach is also used in other RE techniques for promoting                   • Perform Requirements Change Impact Analysis:
agreement, without necessarily making the goals explicit                         Requirement Management not only includes
[48]. For example, in Quality Function Deployment (QFD)                          process of managing documentation but also
[49], matrices are constructed to compare functional                             process of recognizing change through continued
requirements with one another and rate their importance                          requirements elicitation, re-evaluation of risk, and
rather explicitly identifying stakeholder goals.                                 evaluation of systems in their operational
    After agreeing of the requirements, teams should begin                       environment. Thus, each proposed change needs to
“testing” as soon as they have requirements in hand.                             be evaluated in terms of existing requirements and
Deriving test cases from use cases and scenarios is a valuable                   architecture so that the trade-off between the cost
way to find problems in the use cases themselves, in                             and benefit of making a change can be assessed.
functional requirements derived from the use cases and in                   Finally, the process of identifying core requirements in
analysis models created from the requirements [18].                     order to develop architectures that are (a) stable in the
E. Requirement Management                                               presence of change, and (b) flexible enough to be customized
                                                                        and adapted to changing requirements, is one of the key
     Managing change is a fundamental activity in RE [50]
                                                                        research issues in software engineering [53].
as every successful software system evolves due to change
in the environment it is operating as well as change in the

                                                                                                    ISSN 1947-5500
                                                         (IJCSIS) International Journal of Computer Science and Information Security,
                                                                                                        Vol. 8, No. 8, November 2010

   VI.    REQUIREMENT ENGINEERING: CHALLENGES AND                            techniques that swell efficiency and accuracy. By
                    SUGGESTIONS                                              following these steps, teams can gain better
    As mentioned earlier, Requirement Engineering is a                       estimation and thus, superior predictability for
core process as well as most crucial part in software                        software delivery.
development life cycle. Bugs in requirements may not be                 •    Specification: Improve Quality through More
identified during development phase rather they remain                       Effective Communications
concealed until system becomes operational and customer                           Requirements specification includes adding
requirements are not met. Poor requirements cause not only                   detail to requirements incrementally to the optimal
modifications in requirement specifications but also require                 level for validation, design, coding, testing and
re-designing, re-implementing and retesting for entire                       documentation. To ameliorate quality, teams
software. Therefore, requirement engineers have to struggle                  should formulate and automate their existing
and conquer uncountable numbers of challenges for                            requirements specification process by defining a
developing effective and efficient software.                                 standard hierarchy of requirement types and
    Anticipating requirement engineering challenges will                     developing standard templates to ensure
grant opportunities for requirement engineers to enhance                     completeness. They should also identify various
software success rate. There have been many investigations                   specification techniques and apply technology for
conducted to explore different challenges in various                         capturing requirements in a meaningful, easy-to-
domains of requirement engineering. Some suggestions to                      understand way. Traceability across the lifecycle
overcome these challenges are discussed below:                               allows teams for better prediction of the impact of
    • Elicitation: Reduce Rework by Capturing Better                         change and proactively communicates those
          Information                                                        changes to all team members affected. Through
               The process of capturing requirements in                      these steps, software defects can be reduced nicely
          context,     requirements     elicitation   includes               because in this case development teams have a
          identifying     key     business     and   technical               better understanding of requirements.
          stakeholders, getting commitment to stakeholder               •    Agreeing and Validation: Improve Accuracy and
          involvement, selecting appropriate elicitation                     Completeness of Requirements
          techniques and capturing requirements and                               Requirements validation involves verifying
          scenarios in a simple to understand form. For                      whether the specification is inclusive and clear
          reducing rework, teams should mature their                         enough for the development team to understand
          existing requirements elicitation process by helping               exactly what it needed. It also includes validating
          to define responsibilities and stakeholders, identify              whether the requirement of the key stakeholders
          appropriate elicitation techniques and train team                  are consistent with the original need and intent of
          members to use the right techniques. They should                   the business. To improve accuracy, teams should
          also take initiative to capture user scenarios in a                mature their existing process by automating
          simple, visual form that is easy to understand by                  validation and verification to drive adoption and
          the user and accelerate elicitation with interactive               enforcement and improving consistency and
          simulations. Enhancement in communication and                      quality through interactive simulations and
          collaboration among distributed teams throughout                   storyboarding of visual scenarios. These steps trim
          the project lifecycle is also necessary for better                 down software defects, increase satisfaction and
          requirement elicitation. Teams should also improve                 alignment with business stakeholders and thus
          alignment between business expectations and                        enhance business value.
          project deliverables, which increases end user                •    Management: Reduce Costs through Improved
          satisfaction and reduces rework from incorrect or                  Change Management
          incomplete requirements.                                                The process of gathering and managing change
    • Analysis: Reduce Time to Market with More                              requests during the application lifecycle,
          Effective Collaboration                                            requirements management also includes selecting
               Requirements analysis involves verifying,                     changes to be incorporated within a particular
          estimating and prioritizing newly captured                         release and ensuring effective implementation of
          requirements for remaining application lifecycle                   changes with no adverse impact on schedule, scope
          steps. To reduce time to market, teams should                      or quality. To reduce costs, teams should contrive
          codify their existing requirements analysis process                their existing requirements management process by
          by implementing an effective approach to evaluate                  establishing processes for defining and maintaining
          and prioritize requirements for specification,                     requirements baselines and defining a standard
          design, construction and testing. The process is                   process for requesting changes. They may also
          improved through the deployment of tools and                       establish a systematic approach to evaluate and
                                                                             approve change requests so that scope changes and

                                                                                                ISSN 1947-5500
                                                                    (IJCSIS) International Journal of Computer Science and Information Security,
                                                                                                                   Vol. 8, No. 8, November 2010

            affected commitments are managed. By improving                          [16] Finkelstein, A. (1993). Requirements Engineering: an overview. 2nd
                                                                                         Asia-Pacific Software Engineering Conference (APSEC'93), Tokyo,
            ongoing change management, maximizing business                               Japan, 1993.
            impact, while minimizing schedule and scope                             [17] Nuseibeh, B. (1997). Ariane 5: Who Dunnit? IEEE Software, 14(3):
            impact, satisfaction of business stakeholders can be                         15-16.
            increased.                                                              [18] White Paper on “Effective Requirements Definition and
                                                                                         Management: Improves Systems and Communication”, Borland
                          VII. CONCLUSION                                                Software Corporation, May 2009.
    RE is often treated as a time-consuming, bureaucratic and                       [19] Gottesdeiner, E., Requirements by Collaboration, Addison- Wesley,
contractual process and due to ineffective RE; customers
                                                                                    [20] Standish Group, "The Chaos Report,", 1995.
may not be satisfied with the developed system. This attitude
is changing as RE is increasingly recognized as a critically                        [21] Hofmann, H., and F. Lehner, “Requirements Engineering as a
                                                                                         Success Factor in Software Projects,” IEEE Software, 18, 4 (July/Aug
important activity in the field of Software Engineering. The                             2001), pp. 58-66.
novelty of many software applications, the speed with which                         [22] Sharp, H., Finkelstein, A. & Galal, G. (1999). Stakeholder
they need to be developed, and the degree to which they are                              Identification in the Requirements Engineering Process. Workshop on
expected to change, all play a role in determining how the                               Requirements Engineering Processes (REP'99) - DEXA'99, Florence,
systems development process should be conducted [6]. In                                  Italy, 1-3 September 1999, pp. 387-391.
future, RE will continue to evolve in order to deal with                            [23] Dardenne, A., Lamsweerde, A. v. & Fickas, S. (1993). Goal-Directed
different development scenarios for further amelioration. In                             Requirements Acquisition. Science of Computer Programming, 20: 3-
this paper we discussed RE in detail with challenges and
                                                                                    [24] Johnson, P. (1992). Human-Computer Interaction: psychology, task
some suggestions. We believe that effective RE will continue                             analysis and software engineering. McGraw-Hill.
to play a key role to ensure success of a project in developing
                                                                                    [25] Schneider, G. & Winters, J. (1998). Applying Use Cases: a practical
quality software.                                                                        guide. Addison-Wesley.
                                                                                    [26] Jarke, M. & Kurki-Suonio, R. (1998). Guest Editorial - Special issue
                              REFERENCES                                                 on Scenario Management. IEEE Transactions on Software
                                                                                         Engineering, 24(12).
[1]    Roger S. Pressman, “Requirements Engineering,” in Software                   [27] Maiden, N. & Rugg, G. (1996). ACRE: Selecting Methods For
       Engineering: A Practitioner’s Approach, McGraw-Hill, Fifth Edition,               Requirements Acquisition. Software Engineering Journal, 11(3): 183-
       pp. 271-298, 2001.                                                                192.
[2]    Reifer, D.J., “Requirements Engineering,” in Encyclopedia of                 [28] Davis, A. (1992). Operational Prototyping: A New Development
       Software Engineering (J.J. Marciniak, ed.), Wiley, 1994, pp. 1043–                Approach. Software, 9(5): 70-78.
       1054.                                                                        [29] van Lamsweerde, A., Darimont, R. & Letier, E. (1998). Managing
[3]    Zave, P., “Classification of Research Efforts in Requirements                     conflicts in goal-driven requirements engineering. IEEE Transactions
       Engineering”, ACM Computing Surveys, 29(4), pp. 315-321, 1997.                    on Software Engineering, 24(11): 908-926.
[4]    Brooks, F.P. Jr. No Silver Bullet: Essence and Accidents of Software         [30] Chung, L., Nixon, B., Yu, E. & Mylopoulos, J. (2000). Non-
       Engineering. IEEE Computer, 10-19, April 1987.                                    Functional Requirements in Software Engineering. Boston: Kluwer
[5]    Stevens, R., Brook, P., Jackson, K. & Arnold, S. (1998). Systems                  Academic Publishers.
       Engineering: Coping with Complexity. Prentice Hall Europe.                   [31] Maiden, N. (1998). CREWS-SAVRE: Scenarios for Acquiring and
[6]    Bashar Nuseibeh and Steve Easterbrook, Requirements Engineering:                  Validating Requirements. Automated Software Engineering, 5(4):
       A Roadmap, In ICSE '00: Proceedings of the Conference on The                      419-446.
       Future of Software Engineering (2000), pp. 35-46.                            [32] Shaw, M. & Gaines, B. (1996). Requirements Acquisition. Software
[7]    Carter, R., Martin, J., Mayblin, B. & Munday, M. (1984). Systems,                 Engineering Journal, 11(3): 149-165.
       Management and Change: A Graphic Guide. London: Paul Chapman                 [33] Goguen, J. & Linde, C. (1993). Techniques for Requirements
       Publishing/Harper and Row.                                                        Elicitation. 1st IEEE International Symposium on Requirements
[8]    Wieringa, R. J. (1996). Requirements Engineering: Frameworks for                  Engineering (RE'93), San Diego, USA, 4-6th January 1993, pp. 152-
       Understanding. Wiley.                                                             164.
[9]    Robertson, S. & Robertson, J. (1994). The Complete Systems                   [34] Viller, S. & Sommerville, I. (1999). Social Analysis in the
       Analysis: The Workbook, The Textbook, the Answers. Dorset House.                  Requirements Engineering Process: from ethnography to method. 4th
                                                                                         International Symposium on Requirements Engineering (RE'99),
[10]   Posner, M. I. (Ed.). (1993). Foundations of Cognitive Science. MIT                Limerick, Ireland, 7-11th June 1999.
                                                                                    [35] Potts, C. (1997). Requirements Models in Context. 3rd International
[11]   Goguen, J. & Jirotka, M. (Ed.). (1994). Requirements Engineering:                 Symposium on Requirements Engineering (RE'97), Annapolis, USA,
       Social and Technical Issues. London: Academic Press.                              6-10 January 1997, pp. 102-104.
[12]   Lehman, M. M. (1980). Programs, Life Cycles, and Laws of Software            [36] Wiegers, K., Software Requirements, Microsoft Press, 1999.
       Evolution. Proceedings of the IEEE, 68(9): 1060-1076.
                                                                                    [37] Gravell, A. & Henderson, P. (1996). Executing Formal Specifications
[13]   Burg, J. F. M. (1997). Linguistic Instruments in Requirements                     Need Not Be Harmful. IEE Software Engineering Journal, 11(2):
       Engineering. Amsterdam: IOS Press                                                 104-110.
[14]   Boehm, B. W. (1981). Software Engineering Economics. Englewood               [38] Maiden, N. A. M. & Sutcliffe, A. G. (1992). Exploiting Reusable
       Cliffs, NJ: Prentice-Hall.                                                        Specifications Through Analogy. Communications of the ACM,
[15]   Nakajo, T. & Kume, H. (1991). A Case History Analysis of Software                 34(5): 55-64.
       Error Cause-Effect Relationships. Transactions on Software                   [39] Fickas, S. & Nagarajan, P. (1988). Critiquing Software
       Engineering, 17(8): 830-838.                                                      Specifications: a knowledge based approach. IEEE Software, 5(6).

                                                                                                                    ISSN 1947-5500
                                                                     (IJCSIS) International Journal of Computer Science and Information Security,
                                                                                                                    Vol. 8, No. 8, November 2010

[40] Holzmann, G. J. (1997). The Model Checker Spin. Transactions on                  Abdullah Al Mahmood received his
     Software Engineering, 23(5): 279-295.                                            B.Sc. (Engg.) in Computer Science and
[41] IEEE            830-1998           Standard,          found           at         Engineering from Khulna University            of Engineering and Technology
     1998_desc.html                                                                   (KUET), Bangladesh in 2009. His
[42] IEEE           1233-1998            Standard,         found           at         research interest includes Robotics,           Artificial    Intelligence,     Internet
     1998_desc.html                                                                   Security and various areas of Software
                                                                                      Engineering      like      Requirement
[43] Heitmeyer, C. L., Jeffords, R. D. & Labaw, B. G. (1996). Automated
                                                                                      Gathering, Requirement Prioritization
     Consistency Checking of Requirements Specifications. IEEE
                                                                                      and Software Security. He has
     Transactions on Software Engineering and Methodology, 5(3): 231-
     261.                                                                             coauthored a good number of research
                                                                                      papers published in International
[44] Jackson, M. (1995). Software Requirements and Specifications: A                  Journals and Conference Proceedings.
     Lexicon of Practice, Principles and Prejudices. Addison Wesley.                  Currently he is working as a researcher
[45] Easterbrook, S. M. (1991). Resolving Conflicts Between Domain                    of Panacea Research Lab, Dhaka,
     Descriptions with Computer-Supported Negotiation. Knowledge                      Bangladesh. He is also a lecturer at
     Acquisition: An International Journal, 3: 255-289.                               Institute of Science, Trade and
[46] Robinson, W. N. & Volkov, S. (1998). Supporting the Negotiation                  Technology, Dhaka, Bangladesh and a
     Life-Cycle. Communications of the ACM, 41(5): 95-102.                            Project Coordinator of Technocrats
[47] Boehm, B., Bose, P., Horowitz, E. & Lee, M. J. (1995). Requirements              BD.
     Negotiation and Renegotiation Aids: A Theory-W Based Spiral
     Approach. 17th International Conference on Software Engineering                  Farin Rahman received her B. Sc.
     (ICSE-17), Seattle, USA, 23-30 April 1995, pp. 243-254.                          (Engg.) in Computer Science and
[48] Karlsson, J. & Ryan, K. (1997). Prioritizing Requirements Using a                Engineering from Khulna University
     Cost-Value Approach. IEEE Software: 67-74.                                       of Engineering and Technology
[49] Hauser, J. R. & Clausing, D. (1988). The House of Quality. The                   (KUET), Bangladesh in 2009. Her
     Harvard Business Review(3): 63-73.                                               research interest encompasses with
                                                                                      different    sectors   of    Software
[50] Bohner, S. A. & Arnold, R. S. (Ed.). (1996). Software Change Impact              Engineering       like    Requirement
     Analysis. IEEE Computer Society Press.                                           Engineering, Software Security and
[51] Estublier, J. (2000). Software Configuration Management: A                       Software Maintenance. She is working
     Roadmap, In ICSE '00: Proceedings of the Conference on The Future                as a researcher in Panacea Research
     of Software Engineering (2000), pp. 279-289.                                     Lab and also as a lecturer in Daffodil
[52] Ghezzi, C. & Nuseibeh, B. (1998). Guest Editorial – Managing                     Institute of Information Technology,
     Inconsistency in Software Development. Transactions on Software                  Dhaka, Bangladesh.
     Engineering, 24(11): 906-907.
[53] Garlan, D. (2000). Software Architecture: A Roadmap. In ICSE '00:
     Proceedings of the Conference on The Future of Software
     Engineering (2000), pp. 91-101.                                                  Sk. Md. Nahid Hasan received his
                                                                                      B.Sc. (Engg.) in Computer Science and
                                                                                      Engineering from Khulna University
                                                                                      of Engineering and Technology
                          AUTHORS’ PROFILE                                            (KUET), Bangladesh in 2010. His
                                                                                      research interest includes different
                                                                                      areas of Software Engineering like
   Mohammad Shabbir Hasan received                                                    Software      Metric,     Requirement
   his B.Sc. (Engg.) in Computer Science                                              Gathering, Software Security and
   and     Engineering     from   Khulna                                              Software Maintenance. Digital Image
   University of Engineering and                                                      Processing is also one of his research
   Technology (KUET), Bangladesh in                                                   concerns. Currently he is working as a
   2008. His research interest includes                                               researcher of Panacea Research Lab,
   different     areas     of    Software                                             Dhaka, Bangladesh. He is also a
   Engineering       like     Requirement                                             lecturer of Department of Computer
   Engineering,       Software    Metric,                                             Science and Engineering in Institute of
   Software Security and Software                                                     Science, Trade and Technology,
   Maintenance. He has coauthored                                                     Dhaka, Bangladesh.
   numerous research papers published in
   International Journals and Conference
   Proceedings. Currently he is working
   as a researcher of Panacea Research
   Lab, Dhaka, Bangladesh. He is also a
   lecturer of Department of Computer
   Science and Engineering in Institute of
   Science, Trade and Technology,
   Dhaka, Bangladesh.

                                                                                                                      ISSN 1947-5500

To top