Software Engineering Discussion

Requirements Elicitation Difficulties or Challenges

PART 1:

Describe three (3) requirements elicitation difficulties or challenges from the examples below. Give an example of one of these challenges from your experience or otherwise.

• ·         The development team doesn't know enough about the application or the application domain

• ·         The customers do not understand what the software can do for them
• ·         A lack of common background between the customer and the development team
• ·         Requirements change throughout the entire software lifecycle

 PART 2: Respond to peer posts

Post from Megan

The book lists a few challenges to requirements elicitation. One of the biggest challenges can be that the development team doesn't know enough about the application or the application domain. Often times a development team is approached to create a product, the team doesn't know anything about the customer's business or any past applications that have been used. Two ways to help this is to make sure that the customer is collaborating and that there is an active user involvement throughout the elicitation process. Another issue arises from users or customers not understanding what the software can do for them and therefore they don't know how to express their needs. For users who didn't have a  system before or maybe didn't have a well developed system, it can be hard to know what to expect the developers to create or how to tell them your needs. Finally something that ties into both of the previous issues, is a lack of common background between the customer and the development team. 

personally, i have experienced all three. I work for a company that has an in house development team. They prefer to hre people who have experience with the company's main business side. Still some of the developers don't have any idea and don't spend the time to learn. Customers don't have the opportunity to share what their needs are. 

 Post from Stephen

There are many difficulties determining what requirements there will be in software development. At some point in the process, these difficulties have to be overcome and management, developers, and sometimes users have to come to a middle ground to assist in solving problems and producing the final product. From the textbook, I feel that these are some of the more important difficulties in the software development process.

“The development team does not know enough about the application and application domain”

This is a common malpractice among software development. Many projects will require an in-depth knowledge about the software product and what its intent is. The problem this can pose is that managers may hire people that are skilled in programming, but the programmer may not fully understand what the project is.

“Requirements change throughout the entire software life cycle..”

We can see this in various software platforms that we use in our everyday lives. Such as our phones that receive updates to the OS quarterly or annually. These changes can come out due to security risks posed within the OS, known bugs that have been fixed, or minor interface changes. This is something that could always happen or rarely be needed for some software types.

“Customers and users do not know what software can do and how to express their needs.”

The basic statement means that users/customers may not know what the full functionality of their software is or how to express what they would like to see changed in later updates. Again, I will refer to the use of a cell phone. Some of the older users may not know the full utilization and assistance that the iPhone can provide by using Siri. With only touching the button, you can ask Siri to do a multitude of tasks for you such as searching for pizza or scheduling an appointment. One of the best methods of soliciting user feedback is using alpha and beta testing.

Experience

I do not have any particular experience in the software development process. However, I will try to relate on the user end of the software. The program I use every day in my profession has been around for almost two decades. About every two years the company in charge of the program solicit the users of the program to see what functions are working and not working the software and also changes they would like to see with future updates.